When you save and open files across a network or from removable media, many variables affect application performance. Consequently, some problems occur more frequently when you work across a network or removable media than when you work from a local hard disk (for example, damaged files, denied access, or slow performance). In these situations, Adobe Illustrator may return one of the following error messages:. 'Could not complete this operation because this file is in an unknown format.' . 'Could not complete the request because the file is locked.' .
'Could not save because of a disk error.' . 'File is busy.' . 'Can't save the illustration.'
The location dialog boxes open to is determined by the application via a parameter they pass into the API call. If the application doesn't store the last used location, or always passes in the same location, there's not much you can do about it. InDesign stores information about plug-ins, features, and the app itself in its preference files: the InDesign SavedData and InDesign Defaults files. A damaged InDesign preference file can cause unexpected behavior with an InDesign document.
. 'Missing file.' Note: Problems using Illustrator files across a network or from removable media can be intermittent or delayed. Adobe Technical Support only supports using Illustrator on a local hard disk. It's difficult to re-create or accurately identify network- and peripheral-configuration problems.
Illustrator supports working across networks and from removable media and is vigorously tested across multiple network configurations. However, not all existing network configurations which include different software, hardware, settings, and access rights have been tested. Therefore, your network or network configuration can cause errors, crashes, or unexpected behavior. Illustrator is a resource-intensive application, requiring more RAM and hard disk space than most other applications. While you can use Illustrator files from networks and removable media, you can compromise the performance and reliability of the application.
For example, Illustrator reads and writes file data while you work on a file. Therefore, the access speed of the disk containing artwork or Illustrator scratch disk files determines how quickly Illustrator can process image data. Internal hard disks have faster access speeds than network servers (that is, a hard disk accessed over a network) or removable media. Organizations use many different network configurations (for example, multi-launch, client-server, or peer-peer) and types (for example, ethernet, token ring, or IP). Each configuration requires specialized software and hardware, with varying set-ups, preferences, and updates. This additional layer of software and hardware can impact application performance.
(For example, the amplitude of line noise, RF interference, or packet collisions are all factors that impact the reliability of the network.) Multiple factors affect data transmission along a network, including file servers, routers, bridges, network cards, software, cables, connectors, power cables, and power supplies. Network connections can suddenly become unavailable, increasing the risk of data loss and application error.
During transmission and reception, network software verifies that data has been sent and received. The depth of verification depends on the network software package, and may not be accessible by the operating system. Saving files on a network drive or placing linked files in Illustrator from a network drive can slow down Illustrator, or corrupt your files. Additionally, you can receive the error, 'Could not complete the request because the file is locked,' or 'Could not save because of a disk error.' However, the network and operating system may not notify you if an Illustrator file or scratch disk file contains damaged or incomplete information. Technical Support strongly recommends working in Illustrator directly on the local hard disk.
To prevent data loss, save files to your hard disk first. Then transfer them to the network or removable drive in the Finder or in Windows Explorer. To retrieve files, copy them in the Finder or in Windows Explorer from the network or removable drive to your hard disk.
You can then open the files in Illustrator. This workflow avoids problems that occur when network system setups or removable media device drivers are incompatible with the operating system or Illustrator.
If you work directly from networks or removable media and you experience problems, use the suggestions below to troubleshoot. Different factors can cause problems, including memory conflicts among device drivers, damaged or conflicting files, operating system software, hardware, or low-level DOS (Windows) problems. Disclaimer: The following instructions are provided as a courtesy. Adobe Systems doesn't support troubleshooting of networks or of removable media products. Make sure that you install the latest update for Illustrator. Transfer the file to a local hard disk, and then open it in Illustrator.
Use another computer connected to the same network or type of removable media. Set the scratch disks to a local hard disk.
Check with your network administrator to determine if there are any known issues with the network or if a network configuration (for example, updated drivers or changed access privileges) has been changed.
@bentoms The problem with SMB is it lacks the auto-reconnect feature of AFP 3.x, so there is a 120 second window for any network anomaly to resolve itself, so the session ID is preserved and open documents can be saved without fear of corruption. We've been supporting Xinet, Helios, etc., environments for years, and integrators like IO Integration, NAPC, etc., design and build infrastructure allowing users to work off the server. I think some solutions even allow locking the file on the server so only one person can work on it at once, although SMB is still a problem (from what we've seen). Personally, I'd go with what Adobe supports.they're your support, so if you don't follow their lead and the $#!+ hits the fan, you might find yourself stranded. I guess we're risk takers. We have a really reliable and fast network (most places 1Gb to the desktop) and really reliable W2K8R2 servers (now on Nexus hardware with 10Gb uplinks) with fast disk (Direct Attached Storage, Dell MD1200 I believe) on the shares that need it (although we're not coming close to peak IO). Now, on the Windows workstation side of the house we're even ballsy enough to capture and edit HD video projects over the network on the Windows share.
We've rarely had issues. On the Mac side of the house there isn't as much video editing in Premiere Pro, more iMovie so you HAVE to work locally really, but a lot of use of Adobe Photoshop, Dreamweaver, and InDesign and they often work over the network via SMB, to the same servers. Unless I'm not being told things, no real complaints. You didn't really say what products you were looking to use. Are Adobe's recommendations the way to go if you have support issues, absolutely. I haven't had issues that have required support and I fear for my life and time if I actually needed their support.
Working locally will always eliminate the 'what if' the network or server goes down. I would argue the same about 'what if' the internal hard drive failed on the workstation, unless you have RAID? At least in my server environment there is RAID to help protect against that. Also, the business of copying up files, especially large raw video files, adds additional time going back and forth. For us the risk has been worth the reward in time saved, access to files from any workstation, ease for the user, and data integrity.
If you lack confidence in your servers and network reliability (which I have all the confidence in the world in ours) then may want to contemplate that. FWIW we've seen issues like: DreamWeaver keeping files open after the document is closed, closing DreamWeaver on the mac that last opened the file resolves. Our users mainly use Illustrator, Photoshop, DreamWeaver & Flash (those whom edit video always work local). I posted this to the mac enterprise list & was given some versioning solutions to look at, so will have a nose @ that too. We're also migrating these clients from 10.6.8 & cs5 to 10.8 & CS6.
This should help as one of their biggest complaints is share browsing speed. Maybe the speed increase will allow them to give the work local then upload worlkflow a go?
Oh, & the links to Adobe's notes. Adobe's stance for many, many years (and yes, all of us know this stance) has always been 'don't work off of network shares, work local'. It's the same song and dance Quark used back in the day. In the 15 plus years I've been working in the pre-press/printing/advertising world, I've had very, very few issues with working off a network share (from simple AFP share to Xinet share to ExtremeZ-IP share).
The one issue that I see fairly consistently here is a Photoshop saving issue. It is described in this fairly long Adobe forum post: Our environment here is a 9 TB file share on a Promise RAID (RAID 50) connected via FC to an XServe running 10.6.8 hosting the share via AFP. The server has two 1gig connections (bonded) to the network, and all of my users are running on 1gig unless on wi-fi. And it's a variety of client OS from 10.6.8 up to 10.8.2 all running CS 5.5 DP.
My users are used to this Photoshop issue and know how to work around it, but it is annoying. Although I don't work in the creative field anymore, I had once done so managing Macs in such an environment for over a decade, and I have to echo what stevewood is stating. Yeah, it might be considered 'bad practice' to work directly off a server according to Adobe, but for years we did exactly that and had very few issues. The one application that was the most susceptible to files becoming corrupted if there was any issue with connectivity was Photoshop. We occasionally would get a file that just wouldn't open (or if it did it was all weird looking) if it was left open and a server went offline or someone's Mac crashed just when saving the document.
But that's what you have a good backup plan for right? Other than that, the 'work off the server' workflow was generally fine. Besides, getting creative users to comply with a copy locally, work, save, then copy back process, though possible, was akin to herding cats. I would take a look at some versioning solutions to help make that easier if you plan to work that way and not right off the server.
Just my 2ยข for what its worth (probably only about 2 cents). @stevewood wrote: In the 15 plus years I've been working in the pre-press/printing/advertising world, I've had very, very few issues with working off a network share (from simple AFP share to Xinet share to ExtremeZ-IP share). Xinet, Helios, etc., is sold as a workflow solution that facilitates working off the server, whether it's built on AFP 3 or SMB. So your open document survives and remains open (read: user can continue to work). Without auto-reconnect, a user may have the option to Save-As (or whatever it's called now) to the Desktop (say goodbye to defined workflow), or they may not be able to (say goodbye to hours of work). Depending on how these solutions are implemented, if a user works locally it may 'break' the defined workflow (OPI, links, etc.).
SMB doesn't protect you if there is an anomaly, AFP 3 does (up to 120 seconds and your session ID is preserved). There simply is no comparison, although Wintel techs would argue otherwise (they simply don't understand the intricacies of the Mac platform - it's our job to 'teach' them so they can accommodate our needs). It's all about risk.I prefer to take the least risky route whenever possible. Thankfully I haven't had to deal directly with users in the past several years, instead we define workflows and processes and the groups enforce our recommendations (or risk impact to productivity). YMMV.if it works for you, great. Those of us who've been burned know not to stick our neck out. I spent 13 years doing production work, and the next 13 years supporting those environments.
I transitioned to IT because the folks who 'supported' our Macs were knuckleheads who didn't care and couldn't be bothered - the production folks were the squeaky wheel; the 10%. So if/when we lost productivity, it was a joke to them. Trust me, it took less than a year before they dotted line reported to me, and the ones who understood the critical nature of their job continued to work there - and those jokers, well, I hope they have fun flipping burgers. Sorry for the rant, but the issue of risk is a sensitive issue for high intensity production environments, and I hope everyone makes their decision based on continuity and not based on what's easiest for them.