We've been getting this at work too, sometimes various times during the day, sometimes it goes a couple of days without happening. The scariest part is that if it gives you that message and you close the file without saving it again, the file gets deleted and you loose the file. Very, very scary.
But we also found out that if you click ok on the message and save it again straight away (no need for a save as) it works fine.
I posted this a couple of months ago but nobody gave me an answer.
Apparently it's been around for a while... and it's pretty silly that it's not solved in 2010 by either Adobe CS5 or Apple's OS X 10.6.4 . I think though since this doesn't happen with any other files but Photoshop files that I've seem, the Photoshop guys need to look into this and find some new routines to call for saving and/or mitigating locks on files... either way Adobe and/or Apple engineers should squash this lame bug, even if they are in some contention as to who's fault it is and simply serve their customers. Note: this bug is rearing it's head on Xinet Fullpress system that is running K-AShare for it's AFP stack, so it seems less likely to be an OS X filesystem bug but rather Photoshop's handling of file locks? Any Adobe engineers care to enlighten me and my speculations?
A Photoshop error occurs when saving a file to an Apple File Protocol (AFP) network share. Error – ‘Photoshop could not save “file” because write access was not granted’.
When Photoshop saves a document, it deletes the current file, creates a new blank file with the same name, and then attempts to open the new file for writing. Finally, it writes the image being saved to the new file. If any part of this process fails, the original file is lost.
The most common way this error is triggered, is if one user is saving a document while a second user is browsing through the same folder where the document is being saved. The problem happens because when the Finder reads a file to create a preview, a write lock is placed on the file so that it cannot be changed while it is being read. Due to this write lock by the second user the first user is unable to save changes to the file that they just created. Although the timing has to be just right, with many users browsing the directory, the issue can occur frequently.
This error is reproducible against any file server using either AFP or SMB – it does not specifically relate to ExtremeZ-IP. Theoretically the same error can occur even when saving a file locally. You can also trigger the error by having a second Mac browsing for a file in Photoshop or another application’s open dialog.
There is not much that can be done other than reattempting the save, using “Save as” with a unique filename, or saving locally and then copying to the server.
It is a good idea (although maybe not feasible depending on the environment) to avoid having more than one user working on files in the same folder. Photoshop has a number of problems when saving over a network and this is just one you may encounter. Adobe specifically does not support saving over the network. Adobe has a product called Version Cue specifically for managing shared files and file versioning.
There is no fix at this time. See workaround
We have looked into it, repeatedly.
And we should not write a file that is in use by another app (even if we could).
There is nothing that Adobe can do about the fact that some other application has the file in use.
We're already doing what we should by not making a mess of your file and telling you about the problem.
When Photoshop saves a document, it deletes the current file, creates a new blank file with the same name, and then attempts to open the new file for writing.
That is incorrect. Photoshop does not delete the current file first.
Photoshop creates a new file with a unique name, writes to that temporary file, then only when the save is completed successfully does it replace the older file. That is known as a "safe save", and even has some OS support for the action.
Finally, it writes the image being saved to the new file. If any part of this process fails, the original file is lost.
Again, incorrect. If the save fails, the original file is left intact. If an original file is destroyed by a safe save, then there is a problem at the file system or operating system level.
So what you are are actualy saying is that Grouplogic made an error in their analysis?
I doubt it... but if they are; please confirm.
For the first time i read something that closely described this odd behaviour.
I lose a lot of files this way. Mostly on SMB-shares, since the locks tend to last a little longer. So I can confirm they really are being purged. And overall files are deleted in the Photoshop file saving process.(!)
Servers don't lose files by accident, but by a sequence of commands which leads to file loss.
If it is a mismatch in architechture between OSX/SMB/Adobe that cannot be solved, please tell us, but don't make things more complicated.
Yes, they made multiple errors in their analysis.
And we haven't found anyone here who has heard from them about the issue.
Files can't be lost in the Photoshop save process without an OS or server level bug.
We don't care about the protocol, we use OS standard APIs for file reading and writing. Beyond that, it is up to the OS and server to work correctly.
Fact is (in my case), files that should be overwritten are only deleted and never get replaced.
Let's assume it is only an OS and Server issue.
Besides normal File lock behaviour cause of Clients opening files simultaniously (which is clearly visisble in Win2003)
it is hard to determine obsolete OS behaviour.
Grouplogic's Extreme-Zip tries to bridge all the gaps Apple and Microsoft have left.
(Eg. Microsoft didn't upgrade apple protocols since WinNT4 and Mac SMB clients aren't trouble free either)
I don't use extremeZip, since OSX 10.5 Apple has upgraded their SMB client to a level which seems to work for most software.
So i only use Aplles native smb client connected to Win2003 server.
Having these Purged files experiences in Photoshop it might be due to:
- Server settings which i can adjust myself if i know what setting or key to modify. (several options in www.macwindows.com)
- A Microsoft/Apple bug (wait for updates?)
If even Extreme-Zip mentions this behaviour, their software bypassed most of the Microsoft architecture.
Even if their analysis of the problem is wrong, mentioning the same behaviour in Extremezip,
made me conclude the above scenario isn't the case, but it might be "by Design" somewhere...
If Photoshop makes the right API calls......
Whats left is the OSX/Finder design or an incompatibilty between MAC/PC that can't be bridged by Apple somehow.
Macs cant sa(f/v)e on windows networks. That would be a pretty bold conclusion.
Thanx for your answer so far,
t've had this occur at 3 different companies using CS3 & 4. i'm an I.T idiot but was told it was something to do with version cue and the server. in all cases it was fixed outside the retouching studio so had nothing to do with the workstation. sorry cant be more specific but that might point you in the right direction
It could be an OS file system issue, an OS network protocol issue, or a ExtremeZIP server implementation issue.
Photoshop seems to work fine with normal SMB and AFP servers, but ExtremeZIP has been problematic for some people.
However, our own testing with ExtremeZIP servers (and we use them extensively) hasn't found any problems. It could be specific ExZIP versions, or running with specific host OS versions that introduces the errors.
And, of course, we've had to code around a lot of Apple file system and networking issues over the years.
The following shots are of test files from a production server running Xinet Fullpress, I mention the extremeZIP article because it is the only seemingly solidly documented article on an issue that quite a few people seem to be having.
So I ran some tests to recreate the problem, because if it can't be recreated it's not a problem in the IT world I know because I am in the IT Dept at an advertising agency here in Chicago administrating over a 130 Macs… so that aside, here's a long winded run down of the tests
I've posted screenshots at:
And a movie of a Save action stuck attempting to save to .afpDeleted file while the source file is not on the server:
These are unlisted galleries and videos and will be removed when no longer needed
2 machines are used for the test
Machine #1 is running OS X 10.6.4 and is browsing the folder with Finder
machine #2 also 10.6.4 with CS5 is saving to the same file at the moment computer #1 is browsing it with Finder and generating a preview
Most times, the file is deleted and replaced, Finder will "kick you out" of the folder when the file is resaved, or other times show no preview, the timing needs to be precise (yet we have users who aren't trying this on purpose at all and manage to have this happen to them!).
When a write error does occur sometimes it says:
"Could not save "name" because write access was not granted" with the correct name used and the files remains.
"Could not save "name" because write access was not granted" with the correct name used and the original file is gone but a .afpDeletedxxxxxxxx file is found in the directory via Terminal
"Could not save "name" because write access was not granted" with the name .afpDeletedxxxxxxxxxx used and the original file is gone although the .afpDeleted file is found via terminal, it can be copied to a name that Finder will not hide, but it's hidden flags are set and 'chflags nohidden' needs to be run for it to appear in Finder
In scenario C, Photoshop will attempt to save to the .afpDeleted name with using Save even though the document name is being displayed properly in the Photoshop window. Using lsof it can be seen that Photoshop have the resource fork in use (only after the 2nd save attempt though), closing all open documents will still have this file in use, only upon quitting will it not be.
I wish I had taken a look at the .afpDeleted flags to see if it was locked or not during this, but lsof results of it being in use is pretty weird!
So here's some more puzzling evidence, thanks for your help.
There might be hope the files are still there!
While researching I found this out...
Go into terminal, to get to the directory where you want to look:
cd [then drag the folder into the terminal window]
and run: ls -la
This will show all files including "dot files" with a period at the front that Finder will not show
If you find one, you need to change the name and undo the hidden flag, here's how:
mv .afpDeletedxxxxxx newname.psd
chflags nohidden newname.psd
I'm going to have our engineers look into the behavior you are experiencing and fix it if its an issue with ExtremeZ-IP.
Group Logic has a dedicated maintenance engineering team ready to fix problems with ExtremeZ-IP. They will review all of the information posted on this thread.
You can help us find the cause faster if you can open a support case here: http://support.grouplogic.com/?page_id=39 We may ask for more information to help us find the problem.
Once we find the problem, if its in ExtremeZ-IP, we will notify anyone who has an open case what we have learned, the schedule for fixing it and work with you to test the fix once its done. As you can imagine, some fixes take longer than others but consistently reproducing the problem is critical first step.
If the problem turns out to be outside of our control, we will pass along the information we to the appropriate contacts at Adobe, Apple or other vendor and assist them in any way we can to address the problem.
With your help, we'll do our best to help resolve this situation promptly.
T. Reid Lewis
Group Logic, Inc.
So same setup, one 10.6.4 laptop browsing the folder at the same time as a write operation, both using SMB to mount the volume.
SMB (on Xinet) is even more unforgiving than AFP:
When you see an error, the files goes, and there is no dot file left either.
Two different error messages are used:
Could not save "filename.psd" because write access was not granted
Could not save "filename.psd" because an unexpected end-of-file was encuntered
Sometimes Save and Save-As will balk at using the same name even though it doesn't show on lsof as being used (I should have tried to 'touch' the same path to see if it was a server lock but I didn't think to at the time) if you change the name it saves fine, try the original name, no-go, it says there's an unexpected EOF. Other times it will save fine after an error that deletes the file.
There are two movies illustrating this (unlisted links)
(this one shows the file dissapearing)
Screeshots are available on Picasa (shots prefixed with SMB):Now while Finder is a common among element in this (can anyone else say that Finder is "looking" at these files like in my tests?)However we only started seeing this when we upgraded our Digital team from CS4 to CS5.This seems to be an issue with these servers as reported here:AFP on Extreme-ZIP - GroupLogicAFP on Mac OS X Server - sean-glossAFP on Xinet - brunerdSMB on Xinet - brunerdSMB on Win2003 - olafbrandSo, do we think all these vendors have broken implementations of SMB and AFP?
Thanks for sharing this background.
Our team has yet to reproduce with CS5 and ExtremeZ-IP so it would be very helpful if one of you who can reproduce against ExtremeZ-IP connects with our team so we can work together to capture the packet trace and other data we need to completely understand the issue.
I agree, its totally wack to point fingers. It only happens PHOTOSHOP guys. Not Illustrator, Not InDesign, Not Apple Keynote. Not anything else. PHOTOSHOP.
For $1499 I expect to be able to save to my server without this kind of Bull&*(#&$ happening.
GOYA. Get off your ***** and fix it. Period. Its your product that has the problem, not us, not apple.
I know it must be frustrating not to have an answer to what seems from the outside to be a simple problem. But it is not as simple as it seems from the outside, and we have a great deal more experience troubleshooting these kinds of errors than most of our users.
We are also frustrated at constantly being blamed for something that we have spent a great deal of time researching and repeatedly found to not involve any code actually under our control. We know from painful experience that these things happen, and can look like it is the applications fault when the error lies in some other part of the system (OS, server, etc.). Different applications using the same APIs, but in slightly different ways, or with slightly different timing can cause bugs to be exposed in the OS and external devices. We've seen that time and again, and we have worked with the makers of the OS and network devices/servers to resolve those problems.
I almost wish it was a bug in our code, because then we could fix it and get on with life. But we have yet to identify this as a bug in our code, but have identified many bugs in external code and devices.
We are not trying to point fingers, we are trying to help our customers get their problems solved so they can continue to do their work. Demanding a fix in Photoshop for something outside of Photoshop's control isn't going to accomplish anything. Working with us to determine the cause of the error in your networking setup - that can help you get your network fixed and you back to productive work again.
well, who can argue with that? I guess thats well put, more than my outburst. I have worked with Adobe to help find and solve a bug in Photoshop 5 and in the end it turned out it was my OS that had to be re-installed, so maybe you are right. It was cool to actually get an email from Russell too...
However, when I am sitting here working (on a sunday) and every 5 minutes I get the error about saving files to the server, and all week long my employees are asking about the same error, well, I want to blame Adobe of course.
So how do I fix my networking setup? its a mac mini snow leopard server straight out of the box with the most generic setup imaginable.
Sorry, I use some terms so often I forget that they're sort of specialized.
API = Application Programming Interface - how an application calls into the OS or OS libraries to get things done.
On your server problem: what OS version are you using, what protocol are you using (SMB, AFP, etc.), and what kind of server (version of that would be helpful, too)?
Mac mini (fall 2010) running mac os X server 10.6.4
protocol? not sure. I share files using os X server's server control panel, where you turn on sharing and select folders to share.
We share a common area on the hard drive with jobs, materials, files etc. All clients have read + write abilities (obviously)
the client machines are all iMac 27" running Mac os 10.6.4.
Well, I am willing to jump in and help out if needed, send more info etc.. Russel can vouch for me I am really not a bad guy when I am calm and collected. ;-)
Do you have any other advice on what might lead to that kind of error? any other software on the client or server end that could be throwing things off?
Check your Photoshop Edit Log.
Both Macs running CS5 that have this problem on our network are registering the save with the incorrect file name in their logs:
Can't offer any explanation as to why Photoshop is doing this because it is a rare event considering how many files we're saving.
My guess is that the remote machine is busy and that, if Photoshop can't get the information it needs within a set time limit, it screws up. The reason for the guess is that ISTR that when throwing this error, Photoshop would also sometimes show Save As dialog boxes with empty file listings or file listings that would appear with a noticeable time lag.
As for the filename -- that's a temporary file, the first part of the safe save.
Then Photoshop calls an OS routine to swap the temp and the file being replaced.
The OS can rename the file as part of the process.
Photoshop doesn't have a timeout like that.
And the save dialog is an OS dialog, not controlled by Photoshop.
This is sounding more and more like another OS bug.
But why is Photoshop making a log entry saying that a file is saved with a temporary file name? That strikes me as odd because it looks as if Photoshop is treating this incorrect behaviour as an ordinary, valid save operation.
The only thing that the user sees is the error dialog stating that it doesn't have permission to write/overwrite a file with the same temporary name. When what has actually happened is that Photoshop *has* already written the hidden temporary file and then either it or the OS has deleted the original.
Unfortunately it's difficult to isolate the problem because it only started happening last year with two new CS5 installations on new Mac Pros running 10.6.5/6. On older Macs we are still using older versions of Photoshop and they've never exhibited this behaviour.
Thinking about it further I'm certain that this rogue behaviour also produces Save As dialog boxes where the both the file list and the file name fields were both empty -- meaning that either Photoshop or the OS (or both) had lost any reference to what the file should be called and whether it already existed in the destination folder.
If this were just an OS bug then I'd expect to see it happening with other applications -- but honestly cannot recall any occasions when this happened.
I did notice that CS4 would often refuse to save files to both remote and local drives if you mounted/unmounted other volumes (not those that you were using) while working on an image.
The only thing that the user sees is the error dialog stating that it doesn't have permission to write/overwrite a file with the same temporary name.
Yes, because that is the error that the OS returns to Photoshop.
When what has actually happened is that Photoshop *has* already written the hidden temporary file and then either it or the OS has deleted the original.
Photoshop wouldn't delete anything until the safe save is completed. We're constantly looking for problems and reporting them to the user and trying to avoid data loss. That's part of why this looks like an OS bug.
Thinking about it further I'm certain that this rogue behaviour also produces Save As dialog boxes where the both the file list and the file name fields were both empty
And, again - that might be true, but it would be further evidence of an OS bug because those dialogs are provided by the OS.
You probably would see it in other applications, if they called the same set of APIs that Photoshop calls. But as we've found - they don't. Photoshop seems to have been the first application to use some of the Cocoa APIs (that, or other applications didn't notice and report all the bugs in those APIs).
Over the years, we've had reports of this same error in many versions of Photoshop. But so far it was always traced to problems with the file server. When the file server software was updated (or replaced), the errors went away.
We'll investigate this again -- but we've never reproduced such a problem with the file servers (many versions, many brands) here at Adobe.
Thanks for looking at this Chris. I can appreciate the difficulties, the reason that we are saving to a shared volume on G5 is because our XServe has developed a fault and it seems pointless bothering to repair it now that Apple decided to knife us business users in the back. They've forgotten who it was who kept them alive during those lean years before iPods, iPhones and iPads
We had this problem occur twice more today and to try and narrow things down here are some notes:
1. Photoshop CS5 is running on a dual Xeon Mac Pro with 10.6.6
2. The shared volume is on a G5 (4x 2.5 GHz PPC) running 10.5.8
3. The connection between them is Gigabit ethernet and an HP ProCurve Switch
4. This is vanilla AFP, ordinary file sharing on 10.5.8 -- no third party server software
5. No other users were accessing the same files and folders when this happened
6. Photoshop's Edit Log doesn't register the problem when the warning dialogue appears -- the log entry only appears if you cancel the dialogue and then try and Save again. The second save still fails.
7. Save As works without a problem -- even if you save into the same directory and use the original file name. There are no warnings about overwriting because the original file has already been deleted.
8. Locating the lost images is easy from the command line using "find . -name ".afpDeleted*" and they work fine if you rename/mv/cp etc.
This problem started for us as soon as the first new Mac in point 1 arrived -- we'd never seen it before. Another similarly specced Mac Pro has the same problem.
Thought I'd try and recreate the problem last night by taking an image that had previously failed to save (156MB PSD) and forcing a continuous edit/resave loop using an AppleScript. Same host Mac and server combination as before.
Arrived at work this morning to find that it has carried out 1,249 saves without an error...
So I'm still assuming that the target disk has to be busy or communication interrupted in some way for this error to occur.
One of my customers had same issue they run Xserve Raid SL Server. and use CS5
used terminal and noticed the permissions of the files were the POSIX permissions which did not relate to the Login authorization of ACL's gave posix owner read/write and appears OK now.
What I ment to say was the POSIX permissions were read only . ODD but that seems to have sorted for now.