I’ve been getting quite a few inquiries about problems saving files from Photoshop directly to
network drives when using the recently released Mac OS 10.5.3. (I’m told the issue can affect InDesign and maybe other apps as well.)
The short story is that we’ve been working closely with Apple to troubleshoot the issue and have identified the cause. Apple is working on a fix, and we expect they’ll release it in the next System Update.
The slightly longer story is that saving directly to a network is a generally bad idea. Here’s what I’ve heard from a contact in engineering:
Directly writing to a network filing system adds a level of complexity, which includes timing issues, network noise, performance, and other potential issues. We’ve occasionally run into bugs with different configurations/combinations, but as there are too many variants for us to reliably test and certify all the clients, servers, hardware and software, we recommend the safer course of working with files locally and then copying them up to a file server when you’re done. While directly reading/writing to network file systems should work in theory, and while we do some limited testing in the most popular configurations to verify that it does, we can not certify that it will work reliably in your configuration.
I know that’s not what you may want to hear, but it’s a long-standing advisory. Saving files locally, then transferring them, offers better performance as well as greater reliability.
I worked at a newspaper and our non-Adobe pagination software that I was forced to use reacted horribly to network saves, often simply not saving the file at all then exiting with an error (and losing your work). We had very similar problems with Multi-Ad Creator, though I didn’t experience as many issues with Photoshop & Illustrator.
That being the case, we started saving locally then copying files to the server. It was a hassle, but not nearly as bad as re-doing work you hated doing the first time around.
So; can’t Adobe write Photoshop to save locally, then upload and delete? Maybe make it an option in the prefs?
Am I missing something that Adobe suggest a manual step that could be automated?
I have always considered saving to a network a bad idea, there is just too much that can go wrong. Keep it simple to protect the file then copy (not move!) it to the network. I mean come on, really how much longer does it take to do that and know your hard work for that deadline is safe and sound?
There is just too much waiting to go wrong at that very moment when you hit the save button 🙂
While I agree that writing to network filesystems is a complex issue, frameworks have already been written and generated by apple to handle the file writing and system calls, that are maintained and tested by them. In fact, they are provided as such so other programmers do not need to recreate the wheel. The entire point of SDK’s and object orientated programming is you don’t have to be responsible for creating a file handling framework that is robust enough to handle network saves.
It would be as if every application that wants to use the internet had to write its own IP stack. It doesn’t, it plugs into the existing one. And just to test, I was able to save a 300mb file out of quicktime and various other applications to network shares without corruption. So why recreate the wheel when it appears someone has built a better one for you?
Xinet, Helios, etc., all support and recommend working over the network, off the server. It makes sense workflow wise. However, the layers of protection in place – tightly controlled layers – ensure things go smoothly. I agree, with some of these statements. Without a robust, fast, stable and highly supported infrastructure in place ($$$), it makes perfect sense to work locally. In shops that have the right stuff in place, no reason to (well, except for this bug). Don Montalvo, NYC
Another thing: The process of copying the file after you save can be easily automated with AppleScript.
etaN: Perhaps some of us can save to a folder with a Folder Action attached that will move/copy the contents to a network location when that content appears.
For many years now, I’ve recommended the Save Locally, Copy Globally workflow–works for me.
Computer networks have been around for at least 20 years. You would think that by now the concept of saving a file to a network disk would have been solved. It’s also unclear whats a network–as a firewire drive is actually a smart device that has it’s own bus and serial protocol–and in fact some “local” drives (especially at the high end) use iSCSI which is really an IP protocol.I have to say that it’s time for Adobe (and others) to realize that networks aren’t some new-fangled flash in the pan. An application should be designed to work with network.Saving to the local machine and uploading works in a one- or two-person environment but is not a production solution.
Here’s an idea. Instead of continuing with the “official position” of “saving directly to a network is a generally bad idea”, how about initiating an immediate testing and qualification of the most popular/common types of networks?
For example, we have a Mac G5 Server running Mac OS X Server 10.4.11, several terabyte hard drives in RAID 0 & RAID 1 configurations, a Dell Gigabit switch, Cat.6 ethernet cables, and all Mac clients (running Mac OS X 10.4.11 & 10.5.2) connecting at Gigabit speed only via the AFP protocol. We are not using home directories stored on the Server.
We have had ZERO problems for several years using CS2 & CS3 to work directly off the Server.
Can anyone here recommend a workflow that is like working off a server, without working directly off a server?
Here is what I would like:
I double click a file on the server in Finder, it saves the file to to a local drive then opens it up with Photoshop.
When I want to save, photoshop would save a file locally, then Finder would copy it over to the network.
Even when I do work locally, I have problems. If I’ve opened a file off the network before, or I have my computer connected to the network, it makes Photoshop go slow. Something to do with mediabrowser.plist.
If there really are a lot of network issues that can’t be solved, it seems that a local cache should be an option built into the tools.
Here’s an idea. Instead of continuing with the “official position” of “saving directly to a network is a generally bad idea”, how about initiating an immediate testing and qualification of the most popular/common types of networks?
Umm, John addresses this already when he said quoted his engineers:
but as there are too many variants for us to reliably test and certify all the clients, servers, hardware and software,
You’ve quoted a single set up that you have, but consider all the variations. It’s crazy talk to say popular/common and think it will be anything other than a very extensive list. Remember, a lot of users are in mixed environments with Apple, MS, *nix, and more operating the networks.
People can take a little responsibility for themselves and test their own particular setup if they really want to save directly to a network location or they can follow the recommendation and save locally and either manually or automatically have that copied over the network.
It’s not a difficult situation 🙂
Apple’s file IO APIs are the ones with the bugs introduced in 10.5.3, that Apple is now working to repair.
And John’s post already explains why you can’t qualify network configurations in any reasonable way.
Photoshop is designed to work with the network — it just cannot anticipate every possible bad network, driver, OS API or server out there. File IO to local disks is usually better tested than network IO, and involves fewer factors that could go wrong. Thus, local IO is generally safer.
To me this hole conversation seems to be a big waste of time. Think about it. A multibillion company develops a (as Apple says) “the most impressive Mac OS X version yet” an it cant even save reliable on a network drive. Thats nuts. Thats like driving a porsche but only in the first two gears! I really wouls like to know how much time Apple or any other big Software Developer invests into unimported GADGETS in comparising to absolut needed functions. Every os version the system gets more bloated with functions I will never use. Cant they just make a small pro system??? For me Apple more an more drifts away from a pro company. Saying that the quality of the latest Adobe products is also far away from what the have been once….
I have used Xinet Fullpress for the past fourteen years and have always worked across the network and I can count on one hand the amount of corrupt files I have encountered. Working locally would be a major step back in time.
Folks, Version Cue is the way to go!
Is there any chance of finding out publicly what the actual issue is? If this is genuinely an OS X bug, then it would be helpful for other developers if they were aware of it so they could avoid it in their own apps.
[You’d need to consult with Apple about those details. –J.]
I might add that looking at a LAN trace of Photoshop damaging a file on the network, I noticed that some of the AFP calls were failing just before the part where it seems to write the wrong data to the file. Since Photoshop didn’t display any error messages, perhaps a part of the problem here is insufficient error checking in the Save routine?
Finally, an observation: Adobe charges hundreds or even thousands of dollars for its applications. Most small developers only charge tens of dollars, yet – apparently unlike Adobe – they would be unlikely to tell their users that network drives were unsupported, and quite likely to move quickly to release some sort of fix or workaround.
I understand that it’s possible to misconfigure a server-based setup and that there are a lot of possible permutations, so as a result Adobe can’t support every possible configuration, but we aren’t complaining about every possible configuration. We’re talking about OS X Server, which (at least in terms of AFP) is quite difficult to misconfigure out of the box, and we’re talking about a problem that plainly has nothing to do with the vagaries of networks and everything to do with the Save code in Photoshop and its interaction with AFP, the standard network filesystem for OS X.
As a result, the hand-waving about not supporting network saves feels to many people like a cynical attempt at fobbing off Adobe’s customers. It would have been better simply to apologise for the problems and to make clear when your customers could expect a fix and/or what needs to happen for a fix to be forthcoming.
Common now guys, I’ve been heralding saving to networked volumes since the end of teh last century, even on a 10 Mbit connection to a Win NT drive using OS 9 (maybe even before that!) This cannot be progress: just like the old saying: it works faster, but it takes longer.
Working locally is risky: just ask someone who ‘backed up’ the wrong way around! You want (your users) to have peace of mind when it comes to dataintegrity, and the odds that a local disk could die is a lot bigger than the demise of data on a RAID system somewhere in a datawarehouse.
So please Adobe, fix it!
Storing files temporary on a local filesystem and copying files to the server after finishing work is not a real solution since lack of server based file locking in this scenario.
What about a colleague working on the same file in the meantime? One person overwriting the work from another as a permanent risk factor? Really?
Opening/saving directly on servers worked flawlessly for decades if the right protocols/APIs were used (that means AFP, Apple Filing Protocol, for server access and the FPExchangeFiles call to ensure no intermediate data corruption can occur).
In my opinion the current problem is more a matter of buggy implementation that needs to be fixed ASAP than the wrong way to work with files in workgroups.
Branislav, I would second your suggestion pro VC if that tool would be able to store/manage data on networked storage in a sane way (same applies to Bridge). But unfortunately this still isn’t possible.
Version cue? You mean Subversion right? 😉
Seriously though… I find the “you shouldn’t save to network” argument a little suspicious. Granted, I’m not a software developer so maybe I should stay quiet… But not catching a bug that big denotes more of poorly written unit testing from Apple than whatever you want to say about Adobe.
Now, we have the proof that Apple doesn’t actually thoroughly check Photoshop compatibility on main OS updates, if they don’t test photoshop, that means they don’t test the whole Suite. That in itself is why you should NEVER update right away…
As for the broader “should I save to network” issue and workflow. If you’re tech savvy enough, look into Subversion, it’s easily the best centralized versionned workflow setup I can think of. And there’re OS X clients that are user friendly enough for creative types who don’t like the command line.
Working with files on network shares dangerous?? This happens constantly in our office (and probably many others) and works flawlessly.
[That’s great, and most of the time it will, under most configurations. Adobe is simply saying, as it has for many years, that saving directly to the network is riskier than saving locally. It involves numerous variables we can’t control. –J.]
We have 60-some Macs that authenticate to OS X server. All our hundred+ user homes reside on the server – none reside on the client Macs. When users log in, everything in their home folders are being read/written over the network – all those pref files, working files, etc.
In an educational environment, saving locally is not an option. Managed clients, student home directories, stable computers are the norm. Maybe we should look at CS3 for Windows. It doesn’t have this issue. (though that could create 1,000 different issues)
Hey John,
While “Don’t save files to the network” might be your advice, in the real world everybody does it. While Apple should keep its end of the bargain up, Adobe should know what its customers do – and that’s work off a network. If major RIP manufacturers have been doing it for many years (and really, they’re required to), Adobe can get it right.
Correct me if I’m missing something here…if the problem is in the network filesystem stack, how is Finder or the cp command going to be any more reliable at writing out the data to a server than Photoshop? (For the proposed save-local-then-copy workflow)
If Finder or cp actually are reliable, and Photoshop isn’t, then what is Photoshop doing or not doing that makes it less reliable, and can that be addressed?
While there are additional complexities in the network stack, I trust the disks in the server in my closet much more than the disk in my laptop. And with gigabit ethernet, it is actually faster too.
I don’t get it. I’v been working in the graphics industry for 20 years. Most of which we’ve been working and saving directly to a server. I have never run into problems other than it being slow early on but that has changed with faster network speeds. In my opinion it is unreasonable to work locally especially when multiple people are working on the same job. And version cue adds more complexity than we need.
This is very simple. Its an apple bug that needs to be fixed so we can all get back to working at full efficiency.
BTW, Thanks John for the update.
Maybe I’m missing something, but why is this a problem on the apple platform but not the windows platform? I’ve been saving all sorts of adobe files on windows networks for 15 years without issues like this. and i don’t see anyone talking about this being a problem on windows (or other non-apple flavors of unix).
i’m not an apple basher, i’ve been a cross-platform guy on and off for those 15 years, but with all of the “apple is so much better than microsoft” stuff i have to listen to when i tell people i’m windows-based, this seems like a pretty harsh limitation on the apple side.
Are people using Bridge to open and close files? Are they using the Adobe dialog box or the finder dialog box? Do any of these variables play into the saving to the network problem?
People seem to have missed the fact that it’s an issue with this particular release of Mac OS X…thus it is *not* an issue Adobe can resolve. Adobe has helped Apple identify the cause and it appears it should be resolved in the next Mac OS X update. And again, John’s recommendation to save locally is just that – a recommendation on the safest way to work (less variables and potential weak points to deal with, thus increased reliability). Why do I feel like I just repeated what John has already stated? 😉
Dan and others. Adobe realizes people do it. People that do it, need to realize the risks of doing it. That’s what the message is about.
It isn’t saying you can’t do it, or even shouldn’t do it… but you should accept the risks/responsibilities for doing it. Run your own tests in your environment before blindly upgrading, and accept that it is riskier and slower than local saves, which this whole bug that got by Apple and Adobe proves. (In some cases, the workflow or productivity gains will make it worth the risks — but that’s a choice you have to make).
99% of the time, you’ll never have problem. If the other 1% of the time you do, you have to realize that YOU accepted the risk. Adobe can’t be responsible for someone else’s filing system or your network configuration.
Flame Fanning here:
This worked Before 10.5.3. That makes this Apple’s error and not Adobe’s.
Almost everytime I get corrupted data when saving over the network it’s because some marketing widget decides to have each of his 50+ underlings stream a video presentation from a remote server. This causes a little problem called network latency to lose data. Our company policy is to have IT host the video on an inhouse server so that can prevent the global network traffic hit. How many of you see policies ignored or bypassed due to inconvienence?
In this sue happy world I can understand Adobe not wanting to be liable for these human caused errors.
“I don’t get it. I’v been working in the graphics industry for 20 years. Most of which we’ve been working and saving directly to a server. I have never run into problems other than it being slow early on but that has changed with faster network speeds.”
You’ve either been extremely lucky or you haven’t worked with thousands of big files. I’ve seen so many corrupted psd files saved over the network in the past 12 years that the headline seemed kind of stupid. And it doesn’t matter if it’s OS X or Windows – my experience with both has been equally bad.
Don’t save over the network if you want reliability.
But for small studios, and large studios saving to a network and working over it is ESSENTIAL to how we organize and maintain files. There has to be a fix to this, and it needs to happen sooner than later.
This talk of not saving files over a network is crazy. I agree with several other posters citing that saving files to network servers has been developed for 20 years or so. Personally, our company has had server setups from the days of Novel in 1989 to our present Xsan based network and never had a problem saving to a server.
As far as being slower, this is just not so in today’s high speed networks. Our gigbit ethernet network is able to move 2.7GB per minute. If there is a speed difference in saving a 50MB file to the network, we’re talking fractions of a second.
Adobe & Apple have a software issue that needs to be resolved … period!
janne:
while i remember some issues 10+ years ago (OS6 or 7?), i don’t remember seeing it since then on any other apple OS.
i’ve worked on windows most of the time over that 15 years–and yes, probably with thousands of large files in photoshop, i work with very large files regularly–and don’t think i can remember ever having a corrupt PSD on a network. maybe that’s anecdotal, but having worked in very large firms and always having some level of either responsibility or connection with the IT side of things as well, i would think it would have come up if there were problems with saving large photoshop files on the network.
Here I go again: it’s an Apple issue – its an issue with Mac OS X. This saving-to-the-network issue has nothing to do with Photoshop or Adobe other then Adobe’s applications helped discover the issue. Adobe has notified Apple of the issue. Apple will fix it presumably in the next Mac OS X update. And it’s an established fact that it is safer and more reliable to save locally then across a network. It seems quite illogical to blame Adobe for a bug in Apple’s OS. Perhaps people are getting hung up on John’s statement, “saving directly to a network is a generally bad idea.” And that point is definitely arguable given modern networking technology. However I see a lot of noise about how Adobe needs to fix this “save over the network” bug when it’s not even a problem with their products!
That explains it. But doesn’t solve it. In Photoshop the first Save deletes the network file, (unexpected end of file message I think) so all I need to do is save again which creates a new one. Simple.
The issue with save local, is the links. To get InDesign CS3 (which also struggles with network saving on occasion) to work sweetly I have to have copies of my links (client logos/files) local too, and then upload tihe InDesign file to the network and re-link (to the master logos/files).Or else I get 5 or six app crashes with the error logs, which can only be resolved by ejecting from all networks and sometimes a reboot.
(does anyone read them by the way? I’ve all but stopped submitting them as nothing seems to have changed in any of the updates).
Usually there is no problem at all to work directly on HELIOS AFP network volumes for Mac users and HELIOS SMB volumes for Windows users. Working with local files in a collaborative workgroup environment is not efficient and introduces problems that files are not current and often are not backed up.
Today’s local disk performance is usually limited (non-raid) to 40-70 MBytes per second. Current servers can easily keep up with this using 1 Gb networks, and 10Gb networks go way beyond this (up to 300 MBytes/s). Check our page: http://www.helios.de/news/news08/N_02_08.phtml, for performance results. Once again, using Photoshop with HELIOS server products has been no problem in the past and the 10.5.3 bug will get fixed.
The real problem is that many non-compliant network protocol implementations, e.g.: SMB from the Mac, will introduce problems. We created a simple testing tool for Macs called “HELIOS File System Test” http://www.helios.de/products/FileTest.phtml which will test the protocol compatibility, and HELIOS LanTest http://www.helios.de/products/LanTest.phtml which can be used to check the performance and reliability of network volumes. These tools are available for free.
So the simple rule is: AFP is best for Mac clients and Apple and HELIOS servers will work fine. SMB/CIFS is best for Windows clients, and Windows Server 2003/2008 or HELIOS PCShare servers will work fine, including file stream, large-file, and creation time support. As long as developers test their applications with the OS native protocols (AFP for Mac and SMB for Windows) they should work fine with compliant servers.
Sorry… I can not longer hear this s… Working on big big projects and copying files on local desktop only because adobe , sorry adobes photoshop team cannot use actuall apis… this ist an adobe programm and adobe has to do that job.
saying “work on your desktop not on the server” is in a world of networks not the right way. indesign server-saving = works / fireworks server-saving = works / illustrator server-saving = works / freehand server-saving = works / photoshop = ???? not / grafikconverter server-saving = works
really, what´s that? customer-mobbing?
in professional grafic-business we need saving without problems on a networkvolume. not only smb, afp is required
All who are saying to work locally and copy files to the server just do not understand or work in a multi-user, server environment.
Your extra steps to copy files to the server is a ludicrous suggestion!
I have NEVER, in 15 years of working in a server environment have had the issues I’m having since this 10.5.3 update! Whether this is Apple’s fault or Adobe’s, it better be fixed quickly.
I have a feeling it is the fault of both parties. Apple is pushing their built-in file structure while Adobe (and others who do not comply 100% with Apple’s built-in file management) are not willing to use Apple’s system.
Maxon’s Cinema4D is also having this problem. I have experienced problems this week in Adobe and Maxon software and have had to make copies locally. What a PAIN!
Stephen,
I’m pretty sure Adobe engineers would be very interested to learn where they are failing to comply 100% with Apple’s filing system API’s. You seem to have inside knowledge that they are failing to do that, so could you please save us all some time and enlighten Adobe where in the stack trace you found that bug? (I think the fact that things worked in 10.5.2, and are rumored to be fixed in 10.5.4, hint that you may be mistaken).
Last I programmed Carbon and Cocoa, the API’s for writing a file was the exact same whether it was a local file, or a remote file. You’d have to go out of your way to figure out if a volume wasn’t local. If you can write a file local 1,000’s of times and it doesn’t fail, that proves that a failure on a remote drive isn’t likely your code, but with the network filing system that is failing. But I only programmed Macs for 20 years, I could be mistaken.
I know that in many cases the problem with not being able to communicate with a network resource has less to do with your client software or your server hardware and more to do with the protocol and it’s requirements. For example TCP/IP + File System Management requires that the time on your PC/Mac be syncronized successfully from a single source with the domain controller so that the server can ensure that the copies of files you are working with are coodinated with the copies sitting on the network. If your systems are out of sync (namely your client side PC/Mac time is ahead of the server time) then you can get a number of “resource not available” …”not found” errors that can goof up your files and trash them.
This is the number one reason for having a working directory on your PC,… so that if your files get wrecked on the server, then your local copies are still safe.
I am sure this will get better, but right now, I don’t know of any OS that automagically asked you “Would you like to syncronize with the domain controller on this network” when you connect to a new network on a portable device… but they all should.
Usually there is no problem at all to work directly on HELIOS AFP network volumes for Mac users and HELIOS SMB volumes for Windows users. Working with local files in a collaborative workgroup environment is not efficient and introduces problems that files are not current and often are not backed up.
Today’s local disk performance is usually limited (non-raid) to 40-70 MBytes per second. Current servers can easily keep up with this using 1 Gb networks, and 10Gb networks go way beyond this (up to 300 MBytes/s). Check our page: http://www.helios.de/news/news08/N_02_08.phtml, for performance results. Once again, using Photoshop with HELIOS server products has been no problem in the past and the 10.5.3 bug will get fixed.
The real problem is that many non-compliant network protocol implementations, e.g.: SMB from the Mac, will introduce problems. We created a simple testing tool for Macs called “HELIOS File System Test” http://www.helios.de/products/FileTest.phtml which will test the protocol compatibility, and HELIOS LanTest http://www.helios.de/products/LanTest.phtml which can be used to check the performance and reliability of network volumes. These tools are available for free.
So the simple rule is: AFP is best for Mac clients and Apple and HELIOS servers will work fine. SMB/CIFS is best for Windows clients, and Windows Server 2003/2008 or HELIOS PCShare servers will work fine, including file stream, large-file, and creation time support. As long as developers test their applications with the OS native protocols (AFP for Mac and SMB for Windows) they should work fine with compliant servers.
What I wonder if is the Adobe warning to not work across the network is so serious that you don’t test that yourselves in beta…you do participate in Apple’s beta process I hope.
I sense corporate rivalry here and that’s sad. Your people should have a desk in the systems department at apple, and visa versa.
I read with interest this post since today I am recovering from a drive failure that has impacted our VC server and many other assets. Our summer student seemed to stumble on the ability to use a VC project file to keep versions of excel spreadsheets via the computer/server and a computer/client. Seemed sweat at first but perhaps there is a problem.
She saved using “save as” over the existing copy. When the file was picked in bridge, the file requested a version comment. Seemed ok. This was done via computer/server and client/computer.
After a night of sleep the computer/server had serious problems on the system drive (were version cue was stored) and all subsequent work moved towards the failure of the system drive.
Having the recent update of 10.5.3 come in this am in tangent with this “seemingly innocent use” of version cue, seems to make me think seriously about what is posted here and wonder if the approach taken was the right one.
I might add that this am I attempted to use photoshop to do a minor open and format change of a file tif to jpg and ps crashed on open, three times. this combination of events, the practice with vc, photoshop crach, 10.5.3 automatic update and hard drive/system failure, makes we wonder what I have experienced.
Surely the right solution is to use VersionCue, isn’t it? That stores files locally, and then allows you synchronise with the server. The version control features are great, too.
To say it’s a bad idea to work directly off a server or over a network is unfounded.
We have an Xserve on a gigabit network on it’s own VLAN with 15 macs and a few printers. We only started having problems when some Macs accidentally updated to 10.5.3 due to a config problem with Software Update.
The Xserve is still 10.5.2.
Not all Photoshop files are affected just some and they can be .tiff, .psd and .jpeg.
These Designers work on 100’s of Photoshop files a day and to have to work locally is just not productive.
Apple will say it’s Adobe’s problem
[They haven’t said that. –J.]
and Adobe will say it’s Apple’s update that is causing it. Regardless I think Adobe are going to have to come out with and update to fix it.
[How do you propose we go about doing so? –J.]
Just for the record I’m having this problem with PSD files saved to an external FW drive as well. I’m looking to somehow salvage a weeks worth of work. As you’d imagine… I’m not too happy. I hope there is fix found soon and although I have backups of my unedited files I do hope I can salvage the work I already completed in these seemingly now corrupt files.
Apple are going to release 10.5.4 to fix this issue according to Apple Insider.
http://forums.appleinsider.com/showthread.php?s=&threadid=87580
I agree with the idea of not “assuring” network saving of Photoshop files for one simple reason:
Who owns the network configuration; aka what is the precise architecture of the network connectivity between the client and the server; is there a direct connection or is there routing involved; are there any active directory restrictions or is it open door policy; are there any server side restrictions on “spawning” that restricts the types of files that can be saved; etc etc etc.
Some of the biggest Digital Asset Management companies on the planet provide their own proprietary method of open and saving files out of their network shares which are controlled by the DAM. One company shares the network disk as a WEBDAV, where it maps a local portion of the users client machine to copy the file in a Check-out fashion, which then lets the user perform work on the file, then the user Checks it back in, which is a file copy of a complete file.
Corruption manifests itself in any situation where the file copy is being executed at the same time as the file creation, so if we were to ask for a change in behavior, it would be that the file is saved locally on the client machine, completely, then copied over and checksum etc.
There is no reason that saving a file to a network share should lead to undiagnosed file corruption…. that is, if the operation does not complete (all the way through the final writes and close, with the close deferred AT THE OPERATING SYSTEM LEVEL until the server has verified that it has received the full contents of the file as reported by the client) without any error returns, the application must inform the user appropriately… for something like Photoshop that would mean displaying an error dialog and probably displaying a new save dialog.
It sounds like Apple is not maintaining complete sync with the remote file server, perhaps returning a successful close to Photoshop as soon as it’s queued up the final data for delivery rather than waiting for the network operation to complete.
I wonder why this seems to be a particular problem with Photoshop, though… is Photoshop playing games with asynchronous file I/O or something?
DavE said:
Your experience is impressive and you may be exactly right. I’m merely a web programmer and user of various video, animation and graphics tools on the Mac. Even though Apple can/will fix this with the 10.5.4 update, my point was that Adobe, Maxon, and I’m sure others, have a good deal of legacy code (especially Adobe Photoshop). Maxon’s Cinema4D is 90-95% platform independent. Therefore, Cinema4D does not take advantage of the complete set of Mac API’s and instead, writes many themselves. Not sure if this includes the network stack, but it’s possible.
Wouldn’t legacy code, or code Adobe, Maxon, and others have written in place of or in addition to Apple’s own API set, possibly cause issues? In the 10.5.3 update, Apple may have “turned off” support for that particular programming call. I see it in the web world of programming. Why not on the OS level as well?
And what is Photoshop Express, and other web apps coming out for that matter, if not working over a “network”?
What is the difference really between saving to a server directly from PS and saving locally and copying to the server? Why is it so difficult for both ways to basically say, “Ok, the file is ready to be placed at this location, here you go”? It should just work. No other software on our systems has problems saving over the network. My design department keeps all projects on a server, which is backed up, and we work on different parts of the projects at the same time. Saving locally doesn’t allow that consistently, because not everyone remembers, through all the deadlines, to copy things back over to the server, AND their individual systems aren’t backed up to the degree the server is. Some people say to use Version Cue (which I’m sure Adobe would like, keep us locked-in to their Suite), but what of the people not using the suite, using a mixture of PS, Freehand, Quark?
How about Adobe and Apple be friends, figure out a way to make sure this works, and let us all get back to being productive, happy Adobe and Mac users?
Well gee, John, someone at Adobe should run over and tell the InCopy/InDesign workflow guys 😉 Per Adobe documentation, the whole workflow is based on working off the network — both InDesign and InCopy uses. It’s been that way since CS1.
Here’s an overview from Adobe’s help files on how ID and IC users read/write over the network to a local file server.
http://livedocs.adobe.com/en_US/InDesign/5.0/help.html?content=WSa285fff53dea4f8617383751001ea8cb3f-7d50.html
AM
I just cannot fathom how an engineer could come up with that bit of tripe. Look, maybe if you had an old 100baseT hub with inadequate throughput you could see an issue. That said, since 1998 I’ve been designing, installing, using and recommending a switched 100baseT and 1000BaseT network client/server based solution for Adobe and Quark products with failures that I can count on one hand, using my thumb and index finger. Literally tens of thousands of images and 2 failures that I can directly relate back to a hard disk about to fail. No issues regarding network timing and no issues regarding background noise. A properly configured client/server configuration using modern RAID and UPS backup systems is far superior to a distributed desktop system any day of the week.
Network saves “not recommended” is a smoke screen to cover the real issues at hand.
Here’s what I have been able to squeeze out of various sources so far: This is an artifact from Adobe’s continued use of old code based on the Carbon API, Apple’s decision to kill the Carbon API (thus no 64bit version of Photoshop anytime soon) and Adobe not being up to speed on Cocoa until CS5 (??) This issue is unique to 10.5.3 and is not repeatable under any other version of the OS from 10.4.11 to 10.5.2.
Is that close enough or do you want to weigh in here John?
The problem has nothing to do with old code, and nothing to do with Carbon, Cocoa (sorry, but it is not magic pixie dust) or even the posix APIs underlying all of it.
The problem has to do with a bug in Apple’s code, that Apple has admitted to, and is fixing.
Adobe’s advice about not saving over the network comes from 20+ years of experience, from guys who setup enterprise networks without breaking a sweat, and who know the internals of the OS kernels, file systems, network stacks and servers rather well. Simply put: there are too many additional points of failure when saving over a network, and saving over a network rarely gets tested well by the OS vendors.
If this is purely Apple’s fault because of some fantasy “bug” in their code — and has nothing to do with Adobe’s development habits — why does it only affect Adobe products? I save non-Adobe files over my home network constantly and have never had a problem.
[Yes, it’s all a big fantasy. Apple engineers are clearly spending their time fixing a bug that doesn’t exist. They’d probably love to hear from you about the error of their non-error-fixing ways. –J.]
Yes, it’s all a big fantasy. Apple engineers are clearly spending their time fixing a bug that doesn’t exist. They’d probably love to hear from you about the error of their non-error-fixing ways. –J.
Uh huh. I still want to if this only affects Adobe apps, and if so, why? What kind of modern app can’t reliably write to network volumes? I do this all the time. I even open, edit, and save documents stored on my iDisk without ever making a local copy. I’ve never had a problem doing this.
What sort of Apple bug only affects Adobe software?
Who said the 10.5.3 bug only affected Adobe software? The most commonly used software is going to be where people notice the problem first….
And conversely, how does an application that works just fine on 10.4.x – 10.5.2 suddenly stop working on 10.5.3 without any changes to that application, unless the bug was in the OS that just changed?
Apple has already admitted that the bug is theirs, and is already pursuing a fix.
Who said the 10.5.3 bug only affected Adobe software? The most commonly used software is going to be where people notice the problem first….
You know, most people don’t use Adobe software, and I don’t doubt that there’s some other obscure crap app out there that’s also affected, but to suggest that saving files over a network is somehow a bad practice to be avoided because of an Apple bug is disingenuous and misleading. Basically this problem is only going to affect you if you use Adobe software. So it begs the question:
Why?
My Os is 10.4.11, but Photoshop CS 3 (10.0.1) crashes every time I try a “save as” TO HARDDISK since a few days.
I’ve just run across a very serious CS3 bug, and I don’t know where else to report it.
On _all_ hardware and OSes I’ve tried, Photoshop CS3 is completely ACL unaware: if we have POSIX permissions which deny writing, that’s it, regardless of the ACLs we get a “file is locked” message. As we no longer have UMask workarounds in Leopard, ACLs are a fundmental part of all the workgroup installs I’m now doing.
This is repeatable in 10.5.4 with ACFS (Xsan), internal HFS+ and AFP shares on MacPros and Macbook Pros; and I got the same result on a mac mini, 10.4.11, internal drive.
Not sure if it’s a Adobe or Apple thing, but I think it needs to be addressed!
Sorry, John, but that is nothing but a huge cop-out.
The operating system is responsible for ensuring the integrity of the data transferred to the file server and literally thousands of applications are able to do this without trouble.
Reading a writing to network volumes works not in theory, but in practice…
…for everyone except Adobe.
Is there a solution to this issue, yet? This thread has pretty much been inactive for over a year while my clients are still bitching about the issue.
Has Snow Leopard for servers fixed the issue?
My clients are running 10.5.7 on their G5 Macs and the server, a 2x2GHz dual-core Intel Xenon with 5GB of RAM with a gigabit Ethernet network.
The art department is only two people. They want to be able to work from the server like they used to–without issue.
I work in a WINDOWS Server environment with PC’s, MAC’s and UNIX machines. This is common. I have worked with APPLE MAC specialists and have shown them heaps of flaws. Many are from mish mashed ACL’s. If you reverse some of the flags certain services start working. Finding this issue was because MAC’s bugged out with samba when it is based on UNIX architecture. I discovered the ACL’s were written back to front. The MAC techs eyes dropped out of there heads. Trying to run afp and samba simultaneously is a big no-no for those who care and use windows servers.
CS3 is a wreck at saving after a modify on MAC’s.
Doesn’t happen on unix or PC. Straight creates work on a MAC. At the price of the software, you should put extra resources into patching CS3 and not just CS4. CS2 is too old.
Dreamweaver is a superbug program that changes file attributes even though a file hasn’t been modified. Not good for most backup systems. Fix this mental behaviour. Fall into line with common sense.
Does anyone at Adobe monitor this blog? Could they give all these people any bit of hope? There are lots of good ideas in this thread about possible fixes – is Adobe listening? Very frustrating…….
Just for the record… I work on a graphic company and we deal with a lot of heavy images for art books.
We use MacPros with 10.5.8 and 10.6.2 and Adobe CS4 softwares.
It is common to lose files while saving them directly to the network. The file just disappears after Photoshop saves it.
We suspect that it’s Bridge’s fault, as it tries to make thumbnails during the saving proccess.
Never found anything helpful on the Forums.
I find it very stupid to tell people to save on the desktop and then copy to the network. It would be a huge mess.
Please, Adobe! Help us! Your products should not have these kind of issues!
Is this issue fixed in photoshop Cs5 version? Under wich OS version?