Copy link to clipboard
Copied
I keep getting the above error when working off of my xserve in photoshop. It is new in CS5 which we have recently upgraded to. Several people at my office are getting it. Sometimes it displays a random name with afp in front of it (I assume it is the temp name when photoshop is swapping out the new file for the old file.) It only seems to happen with psd and psb files. I have write access to the volume in question and it doesn't matter if I am the only one accessing the folder or not. I can save as and it seems to work; but it does delete the file.
Very frustrating. Anybody have any ideas? My IT guys are struggling with it, and one of them used to work on the Flash team as well as at Apple.
Hi everyone,
The recent Mac OS X 10.8.4 released yesterday has specifically named the following fix:
referenced from this Apple KB article. http://support.apple.com/kb/HT5730
If you are still experiencing this issue, please update to 10.8.4 and then re-test in your environment. Please let us know if you are still experiencing issues.
The KB article also mentions this fix:
Copy link to clipboard
Copied
Hi Gary,
As an addendum to your mail, we have run some reasonably extensive testing turning off the Finder preview options, but always seem to start seeing the problem again eventually. I would also add that these previews are written to the resource fork (._MyFile.jpg in the same directory for a file named MyFile.jpg) rather than the actual file and should not therefore hold any write lock over the original file.
However, in the last week or so, we seem to be seeing some success (fingers and toes crossed) with turning off the three preview options in Photoshop's own preferences as per the attached image. We've only been running with these off for a short time so no guarantees, but we can only hope.
Adobe Take Note: This would seem to indicate that your software may be holding a write lock on the file in order to write the preview. Please could you examine this section of your code to see if a resolution can be found here?
Dan
Copy link to clipboard
Copied
Just as a follow on to my previous post and Chris Cox's previous post, I have to say that I am horrified by the lack of helpfulness from Adobe on these issues. The people posting here are not single box copy end users, they are TLP and CLP licensees. My company spend in the region of £20,000 per year with Adobe. I would expect a somewhat less trite response.
I've heard the responses before. I know Adobe don't support working directly off a server. However, that is how large organisations work, it's time you did support it, even if only on a basic level. I'm not asking for support on working over GPRS from a Fuse mounted LTO file system, I'm asking for support on a Mac desktop working from an AFP share hosted by an Xserve on the same LAN and subnet. It's very easy.
I've heard the 'we do more checks' response. It doesn't wash. If that's the case, why don't we see files disappearing with any of the other applications we use, warning or no?
There are some very smart people in this forum, all of whom are willing to help with resolving this. Why do you refuse to engage with us?
Copy link to clipboard
Copied
He probably doesn't want to engage with a penguin of doom....
Anyways, I share your concerns, about Mr. Cox's responses however I would like to add that very few of the posts are actually bad mouthing the Adobe software and that (guessing here) 90% of the posters in this forum are coming here to start conversations with others in the same field to work together to find a solution. I don't think anyone comes here to get a response from an 'Adobe Employee'.
With that being said, I have also implemented your idea about disabling Photoshop's desire to save a preview so we will see how this goes. Ther user I disabled this for informed me he received the error 15-20 times yesterday. He went from never to 15/day. Needless to say this has not been a fun week. I did also notice that spotlight searching was enabled on my share in Server Admin so I disabled it, did not help at all.
If The Penguin of Dooms idea fails here are my next attempts
Implement NFS for the problem user
Bind his computer to the server and implement Kerberos (long over due anyhow)
Would anyone have any other suggestions? Thanks for all the help thus far
Copy link to clipboard
Copied
He probably doesn't want to engage with a penguin of doom....
Mwah haw haw
,o)
Copy link to clipboard
Copied
Dovahkiin27 wrote:
If The Penguin of Dooms idea fails here are my next attempts
Implement NFS for the problem user
Bind his computer to the server and implement Kerberos (long over due anyhow)
We are bound to AD with Kerberos, running Xinet on a RedHat Linux server with a 10gig backbone and 2 gig aggreagated from the clients and while we dont have the issue frequent, we still get it on occasion. We work on very large files (Bus wraps, Baseball Banners, etc.) We have turned off the preview for columns, icons, and will give the Photoshop preference of preview generation a try as well next time it happens. Luckily we have told our users about the workaround of duplicating the file in Photoshop and saving it.
The ridiculous part of all of this is afp has been around how long???? And ironically a new version of Photoshop just uncovered an error that has been there supposedly "forever" and previously we just didnt know about it because we didnt have the super special error reporting from Adobe??? I dont think so....Why did our files save before without crashing when we didnt get notified of an error (even if whatever error Adobe is reporting on was happening)??? Isnt that the real issue here? Adobe claims it is reporting on an "error" that is happening on Apple, but perhaps the act of reporting on it is what is causing the issue? Maybe it is not an error at all, just a change of properties of the file and the reporting of that is what is causing the crash? Has Adobe thought of this??? This is the kind of feedback I am sure a lot of us would like to hear from Adobe what their answers are and what they have investigated, or are investigating to ensure it is not an Adobe issue, but all we hear from them is "Its complicated.....we report on a lot of our vendors errors" While that is all good, what are we supposed to do once we have the report?
At any rate, I sure hope they dont change the way files get saved for their other products in the CS suite to "protect us" with error reporting.
BTW we too are a super user of Adobe products and spend hundreds of thousands of dollars with them annually within our Agency Network. So I understand the frustration.
Copy link to clipboard
Copied
>> Why did our files save before without crashing
We're not discussing crashes at all here, just files that fail to save correctly.
>> but perhaps the act of reporting on it is what is causing the issue?
Nope. The error reporting happens after the OS has returned an error.
>> At any rate, I sure hope they dont change the way files get saved for their other products in the CS suite to "protect us" with error reporting.
So you prefer to quietly lose files on the server to actually being informed of the error coming from the OS? Kind of a "head in the sand" approach to file management?
Copy link to clipboard
Copied
Losing a file because of a .afpdeleted file error to me is a crash. As far as a head in the sand approach, my point was whatever Adobe did to change the way files get saved, seemed to complicate and make the issue worse. Besides, what the &%$#@#$ am I going to do with a report? Re-write my OS or application? Come on, put yourself in our shoes, If you give me a report of an error, give me some resources what to do with that and some workarounds at least. If your going to be proactive and provide reports of other peoples errors, then you must think it is important enough to give some options of what to do with them even if it means making work arounds in your own application to get around the error. If your taking the side that it is "their" problem, the minute you report on it, you are taking responsibility for it from a users perspective. Just think of all the people that dont read this forum that see Photoshop giving them an error when they save. Have you heard anyone say they got an Apple error that Photoshop told me about? No..........Bottom line is we are the clients here, and the more we hear how Adobe changed something and now it doesnt work, the more we (the purchasers of your software) will continue to give Adobe the bad press that they broke it. Especially when we post on a forum to ask these questions and they get so defensive.
Chris Cox wrote:
>> Why did our files save before without crashing
We're not discussing crashes at all here, just files that fail to save correctly.
>> but perhaps the act of reporting on it is what is causing the issue?
Nope. The error reporting happens after the OS has returned an error.
>> At any rate, I sure hope they dont change the way files get saved for their other products in the CS suite to "protect us" with error reporting.
So you prefer to quietly lose files on the server to actually being informed of the error coming from the OS? Kind of a "head in the sand" approach to file management?
Copy link to clipboard
Copied
>> Losing a file because of a .afpdeleted file error to me is a crash.
No, a crash is a very specific thing. Losing a file because of a file system error is not even remotely a crash.
>> whatever Adobe did to change the way files get saved,
All we did was check for more errors.
The OS may change behavior (because it changes from Carbon to Cocoa, and sometimes from OS version to version), but Photoshop really didn't.
We try to tell you about the errors so you know that something went wrong. If you don't know about the error, you don't know that your file was lost. If you know about the error, you have a chance to resave the file.
I'm sorry we don't have a magic wand to wave and solve your problems -- but it is still far better that you know about the OS bug than just losing files at random.
And we are continuing to work with Apple, and working on our code (working around OS bugs) to prevent lost files.
Copy link to clipboard
Copied
And we are continuing to work with Apple, and working on our code (working around OS bugs) to prevent lost files.
Thats good to hear. Is there any kind of ETA on this? What kind of progress can we expect to see in CS6 or CS5.75?
Copy link to clipboard
Copied
There are too many changes involved for a dot release, and this sort of thing needs a lot of testing. So it would have to wait for a major release.
Copy link to clipboard
Copied
Chris,
Is Adobe any closer to fixing the "write access not granted" issue?
BTW, here is my work-around (let me know if you have a better one):
First "Save" or "Save As"....which initiates the error message (file gets deleted but document is still open)...
Second "Save" or "Save As" again. The second save does not collide with the temp file and the same file name can be used. This is good because Lightroom can still find it.
But...I should not be having to do this...it is frustrating, to say the least.
Copy link to clipboard
Copied
I wanted to post this a while ago but thought it best to wait until we'd had a decent test period.
We have been running now for some time with Photoshop's thumbnail creation prefs switched off as below.
Running Photoshop configured this way, we never see the .afpDeleted error. This is a good workaround, and would also seem to be fairly conclusive proof that Photoshop is doing something wrong.
We also found another that for some reason Photoshop decides occasionally to quietly reset these settings. Perhaps Adobe would care to look into this? Can't really blame this one on anyone else.
To remedy this, we run the following script periodically. We run it from Casper as a policy ()with some additional logic code that I'm happy to supply to anyone who wants it), but you could just as easily run it from launchd or a however you please.
I hope this helps everyone suffering out there
Dan
-- set up logging
global docPath
set docPath to (path to library folder from user domain) & "Logs:" as string
global theLogFile
global logString
-- check if photoshop is open
if appIsRunning("Adobe Photoshop CS5") then
tell application "Adobe Photoshop CS5"
--Change Photoshop thumbnail preferences to do with saving thumbnails while logging results
if image previews of settings = yes or image previews of settings = ask then
my writelog("Image previews are set to " & image previews of settings & ", setting to no")
set image previews of settings to no
else
my writelog("Image previews are set to " & image previews of settings & ", leaving alone")
end if
if icon preview of settings = true then
my writelog("Icon preview is set to " & icon preview of settings & ", setting to false")
set icon preview of settings to false
else
my writelog("Icon preview is set to " & icon preview of settings & ", leaving alone")
end if
if Mac OS thumbnail of settings = true then
my writelog("Mac OS thumbnails are set to " & Mac OS thumbnail of settings & ", setting to false")
set Mac OS thumbnail of settings to false
else
my writelog("Mac OS thumbnails are set to " & Mac OS thumbnail of settings & ", leaving alone")
end if
if Windows thumbnail of settings = true then
my writelog("Windows thumbnails are set to " & Windows thumbnail of settings & ", setting to false")
set Windows thumbnail of settings to false
else
my writelog("Windows thumbnails are set to " & Windows thumbnail of settings & ", leaving alone")
end if
end tell
end if
on appIsRunning(appName)
tell application "System Events"
set res to (name of every process) contains appName
return res
end tell
end appIsRunning
on writelog(stringToLog)
set logFilePath to docPath & "com.cp.photoshopresetprefs.log" as string
try
-- Check the file & path exists and are reachable by assigning an alias
set theLogFile to alias logFilePath
on error
-- Likely that the file doesn't exist yet, try touching it and re-assigning the alias
do shell script "touch " & quoted form of POSIX path of logFilePath
set theLogFile to alias logFilePath
end try
-- Make sure another app is not already holding a write-lock on the file by closing it first
try
set logfileRef to open for access theLogFile with write permission
on error errmsg number errnum
if errnum = -49 then
-- close the file
close access theLogFile
-- Try to open it again
set logfileRef to open for access theLogFile with write permission
end if
end try
set endOf to (get eof logfileRef)
set logString to (current date) & tab & stringToLog & return & return as string
write logString to logfileRef starting at (endOf)
close access logfileRef
end writelog
Copy link to clipboard
Copied
The Penquin of Doom wrote:
"We have been running now for some time with Photoshop's thumbnail
creation prefs switched off as below....we never see the .afpDeleted
error."
Unfortunately, this workaround did not change the outcome for me. Here
are additional details which seem to contribute:
In my workflow, I always open images from Lightroom (3.6) and all my
images are on a server. Launching Photoshop 5 this way will always give
me the error and delete my file. I just did some experiments and I do NOT
get the error if I do either of two things...Either don't use the server,
or open files within photoshop using "file>open". I think the second
option will be an easier road for me to take.
Copy link to clipboard
Copied
>> would also seem to be fairly conclusive proof that Photoshop is doing something wrong.
Or you found a way to avoid some of the problematic OS file system calls (mostly relating to resource forks).
Apple is investigating why their APIs fail on some file servers, while we have been working on ways to avoid the problems with the OS file APIs and do a better job of catching non-obvious errors from the file APIs. Photoshop CS6 includes our latest efforts, while we're still waiting for Apple.
>> We also found another that for some reason Photoshop decides occasionally to quietly reset these settings.
That should only be possible if the application preferences get reset.
Copy link to clipboard
Copied
THanks for the update Chris. I was planning on looking at the Beta and
trying it on some files.
Copy link to clipboard
Copied
Chris,
May I make an observation, but requiring a major update to squash these bugs is a bit harsh. Luckily I have migraged our company to the Assurance program and so I will be rolling out CS 6 when I am fully happy with how it works with Lion.
I rarely install .0 versions of any software anymore, even Apple because of the various gotchas that I have lived through. Which means that at best I will be rolling it out 4 to 6 months after you have introduced so that the kinks can be worked out.
Look... I am aware that many companies have gone to the model were they squash bugs in major releases, but this bug really shouldn't wait for that.
John Gibson
Copy link to clipboard
Copied
>> May I make an observation, but requiring a major update to squash these bugs is a bit harsh.
It should be a minor OS update, but we don't have a schedule from Apple yet on when the bugs will be fixed.
While we wait for Apple to fix the bugs, we're rolling out workarounds at our first opportunity, which is CS6.
Copy link to clipboard
Copied
Chris Cox wrote:
Or you found a way to avoid some of the problematic OS file system calls (mostly relating to resource forks).
Apple is investigating why their APIs fail on some file servers, while we have been working on ways to avoid the problems with the OS file APIs and do a better job of catching non-obvious errors from the file APIs. Photoshop CS6 includes our latest efforts, while we're still waiting for Apple.
Which is great for us as we can get on with working.
It's a shame that you couldn't have told us about the resource forks earlier, that may have helped us find a workaround sooner. Generally speaking, regardless of who's fault it is, both you and Adobe have come across as somewhat unhelpful in this matter. Once again, and I'm sure others here would agree, I'm not bothered who's fault it is. We needed some help to find a workaround or solution, as you know the software better than us we asked you. Instead of help, what we got was finger pointing. This has helped no-one and comes across as poor customer service. I'm sorry to have to say this but it is true.
Chris Cox wrote:
That should only be possible if the application preferences get reset.
That's why I see it as an error. It occurs without the prefs being reset, all our other prefs remain intact as far as we can tell.
Copy link to clipboard
Copied
>> That's why I see it as an error. It occurs without the prefs being reset, all our other prefs remain intact as far as we can tell.
That's weird. I don't see any code in Photoshop that could change that value without the user or an action/script changing the value.
But do try the CS6 beta and see if it's improved.
Copy link to clipboard
Copied
Yeah we were a bit bugged out about it too. It definitely happens, but scratch disk settings for instance are left intact.
It's not down to the preference not being written to disk as we tried setting the pref, quitting, re-launching and checking to see it had taken which it had and then some time later (hours, days even a week or so) the pref had been reset.
Anyway, we've worked around.
Copy link to clipboard
Copied
I've been having this issue off an on for about a year, I have found that if you trash the com.adobe.Photoshop.plist file in the user's library, the issue goes away. Put the bad .plist back in the user's Library folder, user can't save.
Chris, I am not sure how this is a bug in Apple's server API if trashing Photoshop's .plist resolves the issue, if only temporarily. Any insight would be greatly appreciated here.
I will report back how long this remedy lasts for.
Thanks
Copy link to clipboard
Copied
Photoshop only writes 2 values into the plist file (language and memory percentage) -- all the rest is OS variables.
If what you report is correct, then it would have to be an OS bug.
And the cases we've seen have been due to known bugs in file servers, or a known bug in the OS file APIs when saving to a file server.
Copy link to clipboard
Copied
This is all that is contained in the plist from Photoshop. The same user is also having a nasty issue with InDesign where oddly enough, removing the InDesgin .plist file resolves the issue.
Also, the saving issue appears to be user specific as fast user switching to another local account on the machine does not reproduce the issue. Sure enough, switch back the to the user account with the issue and the user can no longer save. This with the removal of the .plist from the user library really points this to something wrong in the user Library, not the server
Hopefully this is somehow helpful
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>NSDisabledCharacterPaletteMenuItem</key>
<true/>
<key>NSNavLastRootDirectory</key>
<string>/Volumes/SERVERSHARENAME/•• JOBS - Creative ••</string>
<key>NSNavPanelExpandedSizeForSaveMode</key>
<string>{912, 729}</string>
<key>NSNavPanelExpandedStateForSaveMode</key>
<true/>
<key>oldPaletteFontTypeKey CS5.1</key>
<integer>0</integer>
<key>uiLanguageKey CS5.1</key>
<string>en_US</string>
</dict>
</plist>
Copy link to clipboard
Copied
The only Photoshop values in there are "uiLanguageKey CS5.1" (sets the UI language) and "oldPaletteFontTypeKey CS5.1" (which I think is ignored). Both are default values, and neither have anything to do with files or saving.
The NS values are OS supplied. I don't know why they might affect file saving except for the "NSNavLastRootDirectory" which tells the OS where to default the save dialog the next time it is opened. I wonder if the OS has problems with the folder name (hypens and spaces)?
Copy link to clipboard
Copied
Chris Cox wrote:
I wonder if the OS has problems with the folder name (hypens and spaces)?
I was going to suggest the •• characters myself. What are those? They're hex code 95 from what I can see.
-Noel