Skip navigation

could not save because write access was not granted (Mac OS)

Jan 3, 2012 12:49 PM

  Latest reply: thysonsacclaim, Mar 24, 2014 6:25 AM
Replies 1 2 3 4 5 ... 10 Previous Next
  • Currently Being Moderated
    Apr 5, 2011 7:04 AM   in reply to sean-gloss

    We started to encounter this exact error message after upgrading 3 workstations to OSX 10.6 and Photoshop CS5. The error appears on a random basis on all CS5 stations, roughly once in 3 days. Other Photoshop installations like CS4 or older are not effected.


    All data being worked on is located on our SUN server running HELIOS EtherShare.

    FYI we never had problems working network-based with PhotoShop since the days of MacOS 8.


    Our tech guys found a way to force this CS5 error to occure by setting a write-lock onto the edited files resource path.

    After provoking the error by hitting "Save" there were now two write-locks present on the resource path: the one set by ourselfs and a new one set by the CS5 client while the data path of the file still had no write-locks.


    We then opened support case 0182160238 to adress this problem on March 14th.

    Today we got an automated answer which directed us to info note http://kb2.adobe.com/cps/406/kb406793.html  

     

    Long story short: Adobe will not support any network-related CS5 issues. WTF?!

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 5, 2011 11:37 PM   in reply to Foli_RM

    Hello,

     

    we are the "tech guys" of which Foli_RM speaks;-)

     

    You must set a write-lock (DENY_WR) onto the edited files _resource fork_ . Then save the edited file in PS5 and the error occurs.

     

    Greetings

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 21, 2011 11:43 AM   in reply to sean-gloss

    Well, the answer in my case was simple, after reading some of this I tried saving to a different drive...no problem, good luck all

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 27, 2011 2:58 AM   in reply to sean-gloss

    Hello

     

    I have the same problem as reported above at one of my costumers.

     

    Server used: Helios EtherShare (latest patches)

    Clients: 10.6.4 - 10.6.7

     

    This problem started with CS5 (no problem with CS3 and CS1)

     

    It only occurs with .PSD files. Never with .TIF, .JPG or any other filetypes in Photoshop CS5

     

    It also only occurs with Photoshop. No problem with InDesign, Illustrator or any other third party applications.

     

    I am also intrested in why Photoshop should save in a diffent matter than InDesign or Illustrator. Suggesting that files get lost in these other applications saves because of not using "safe save" is just absurd. You and I would have heard about this a million times from the users by now. A lost file is ALWAYS reported - we all know that. Why not try to implement the same "unsafe save" mechanism as the other applications use with great success?

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 27, 2011 9:20 AM   in reply to Holger Netterby

    Photoshop does a safe save, and uses newer APIs in some cases because Photoshop already moved to Cocoa and the other apps have not.

     

    Photoshop saves PSD files just the same as it saves other files - there is no difference in the APIs used.

     

    Yes, we know that files do get lost in other apps because they don't do a safe save.  We aren't going to intentionally change our code to make you lose data.

     

    But so far this still looks like a major bug in an OS API causing problems on *some* file servers.

    And yet we can never reproduce the problem here with any of our file servers.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 27, 2011 12:09 PM   in reply to sean-gloss

    I´m sorry to play the devils advocate but I still find it strange that the only applications that have ever failed a server save for my customers are the three listed below.

     

    I support around about 75 companies with between 2 - 150 users each, most of them in graphic production. I have during 20 years only ever heard of 3 applications causing a save failure (to a server or locally) on a regular basis. Two of them fatal (IE the files is gone after save attempt) and the third just gives an error.

     

    Microsoft Power Point 2004 - Working on large files sometimes caused the file to vanish from the server (or the local disc) when saved. Was fixed by Microsoft after some updates. Not completely shure but I think this only happend on non-US versions of Office. (sometime between 2004 SP2 - SP3 if I remember right)

     

    Adobe Photoshop - I (my customers) have only encountered this error with CS5 and Helios EtherShare up until now.

     

    Apple Final Cut Pro - Saving gives error -50 unknown file. Workaround - save file locally and then transfer the file to the server. This does not ever cause the file on the server to vanish! (Most FCP versions)

     

    What I want to point out with this is that I can guarantee that I would have heard about files getting corrupted during save. If files is un-openable after a save customers tend to throw themselves on the phone to get support and demand that a backup get retrived. This is just natural behavior. The point being that when I heard this CS5 save error I assume an error in Photoshop CS5 because all other applications work as expected.

     

    Who do you think I should report this error to? Apple or Helios or both?

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 27, 2011 3:43 PM   in reply to Holger Netterby

    I´m sorry to play the devils advocate but I still find it strange that the only applications that have ever failed a server save for my customers are the three listed below.

    They're not the only ones to fail.

    They are the only ones that TOLD you that they failed.

    Again, many applications fail to complete the save and don't do enough error checking to tell you about it.

    And we do hear about files being corrupted or lost when saving to a server, all the time. (and I don't mean just from Photoshop)

     

    We've investigated the problem many times. In the past, it was mostly server bugs, bad networks, and once a bad OS API (that got fixed).

    This time, it looks like another bad OS API that can fail in a way that it is not supposed to ever fail (losing documents).  Since the whole point of that API is to do a safe save and not lose documents, that is particularly bad.  But we can't do much about that.  If we use other APIs, we have other problems.  If we use this API, it is supposed to work, but may require an OS update before it works correctly.

     

    This is one of many reasons why we say to save and open files locally and not off the server -- there's too many things involved that are outside of our control, and that we know go wrong in some situations.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 28, 2011 2:10 AM   in reply to Chris Cox

    >> Photoshop saves PSD files just the same as it saves other files - there is no difference in the APIs used.

     

    If there would be no difference in API's people won't keep reporting this CS5 save error on a broad basis of file servers. Just check back in this thread on how many and different server OSes the error appears.

     

    We did not pay attention to it first but we can confirm what Holger Netterby just reported: the CS5 save error occures only when working with .PSD files. It never happens with .TIF or other formats. Still a network or file server issue?

     

    >> But so far this still looks like a major bug in an OS API causing problems on *some* file servers.

    >> And yet we can never reproduce the problem here with any of our file servers.

     

    We contacted HELIOS about this problem and they found a way how to reproduce this specific CS5 error.

    The important point is: it's not limited to HELIOS EtherShare servers as long as you can access file resource fork information. For example HELIOS used their method successfully on a plain OSX Server's share  - no HELIOS EtherShare involved - to force the error. Read prom-sup's post how it's done.

     

    btw:

    We opened a Adobe Support Case about this problem and were told that the usage of CS4 and CS5 is not supported on network shares. All files to be worked on should be copied to the local drive first, then worked on, then copied back.

     

    Don't you think Adobe's graphical industry customers have better things to do then shuffling Terabytes of .PSD files between servers and clients only to work fine with Photoshop?

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 28, 2011 9:34 AM   in reply to Foli_RM

    If there would be no difference in API's people won't keep reporting this CS5 save error on a broad basis of file servers.

    I'm the one looking at the code, and telling you that there is no difference.

    You are guessing that there is a difference because you see people mostly reporting a similar problem on PSD files.

     

    Still a network or file server issue?

    Yes.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 28, 2011 12:29 PM   in reply to sean-gloss

    Having the exact same problem, UNACCEPTABLE adobe!!! If photo shop doesn't delete the file and is "safe" why does the file disapper, and say it was deleted in the servers access logs. Figure it out, and stop trying to blame the problem on users servers. Copying the file to your desktop to work on it is a big load of crap!

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 28, 2011 12:50 PM   in reply to sean-gloss

    Aside from your complete denial that photoshop deletes the original file, when it clearly does and have the server logs to prove it, why cant you add a dialog that says something like someone already has this file open, do you want to open it as read only.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 28, 2011 2:01 PM   in reply to jackjojoj

    Please read the thread before adding comments.

    (also, this toipic has nothing to do with opening files, so the suggestion about an error message makes zero sense)

     

    We've tested this, many times.  Previously, the problems have been traced to the server or (once) a bug in an OS API.

     

    The current problems appear to be due to an OS API that fails to return an error correctly, and fails to do it's function correctly.

    We do test the files before saving, which is why we put up the warning about files being in use or the user not having access.

    We test the files while saving, and after saving to make sure the sizes are correct, the permissions are right, etc.

    But after all those tests are done, after we've written out the file, we call an OS routine to do the final step - and it is failing.

    Photoshop is not deleting the original file.  Photoshop calls an OS API to replace the original file with the file we just wrote.  But that API fails.

     

    Now, why does it fail for some people and not for most others, and why does it not fail for us unless we force the situation?  We don't know.  Some of that has to do with the server, and some might have to do with OS versions, timing, or the phase of the moon.

     

    Now, we're trying to get this solved - but we can't solve it.

    We have to use the OS API, and the OS API is broken. We could reimplement the OS API, but it would take a lot of work and not be guaranteed to always work.  All we can reasonably do is work with Apple to fix the OS API.

     

    If you want a fix sooner, talk to Apple.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 28, 2011 2:05 PM   in reply to sean-gloss

    Done some more testing. If 2 people have the same file open in photoshop CS 5, mac computers, mac server, the last person to save wins. A little worrisom, it would be nice to know the file is open by another.If one person has the file open in Prieview, and the other has it open in CS 5 and tries to save, the user gets the could not save error, and the file is deleted from the server. So it appears to be an issue if another app has use of the file, but it still DELETES it!!! CS4 does not do this, in the same senario of photoshop and prieview, it says it cant save because the file is in use or left open. Why cant CS5 do this?

     

     

    Dana

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 28, 2011 2:38 PM   in reply to jackjojoj

    it would be nice to know the file is open by another

    There is no way to know that short of using an asset management system that forces checkouts to modify the file.

     

    When a file is opened into Photoshop -- the file on disk/server is closed after reading.  It would break many applications and workflows to hold the file open unless you are actively reading or writing it.   After reading or writing, there is nothing to indicate that someone else has the document open.

     

    Photoshop already checks the file for changes and ask if you want to update, and warns you if the file has been modified before you save.

     

     

     

    PLEASE read the existing thread.  You are asking things that have been answered several times already.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 28, 2011 3:40 PM   in reply to Chris Cox

    Chris, I think people are saying "the same thing" because despite offering up what seems to be a variety of situations in which we are having problems, the response we are getting is also "the same thing": 'Yes we've looked, it's hard to know, but we use "safe" methods'

     

    So we'll keep offering up evidence to the contrary that PS is _actually_ using safe saving methods, because I honestly haven't ever seen this in any other Adobe app and I've been in IT since 2000, supporting CS, CS2, CS3, CS4, CS5, and soon CS 5.5 and from my experience Photoshop has problems with network saves, maybe not as often as some others here, but I've seen my share of truncations, corrupted layers, corrupted files, and deletions.

     

    Speaking of reading the whole thread...

    Back in Octobober 15 and I offer a video of a file being deleted during a save:

    http://www.youtube.com/watch?v=ybXFybcATFA

     

    Depicted is me saving to a file that was being thumbnailed by Finder on another computer It took split second timing to do this but I could recreate it.

     

    The point is not that Finder may or may not have a lock on the resource fork when Photoshop tried to save but the FACT THAT THE FILE DISSAPEARS! Luckily (in that case) it could be resaved without throwing an error, other instances would not allow a resave.

    Bottom line: A USER WOULD ASSUME THE FILE IS SAVED AND QUIT! WORK LOST.

     

    DISSAPEARING FILES DURING A SAVE ISN'T SAFE!

     

    That's why we keeping repeating this because it doesn't seem to be acknowledged: It's not SAFE ENOUGH!

     

    Ensure the file is written, if not, prompt us to try again?

     

    Can these silo'd product team have a meeting come to a consensus on file  saving routines, invent the wheel once and not repeatedly in each product? Although if the PS team thinks ID and Ai are using "usafe" methods then that's a problem, I doubt those engineers on Ai and ID think their methods are substanadard, it seems a bit hubristic for the PS team to say that?

     

    So in the spirit of humility and enlightenment: can this issue be looked at by all the Creative Suite product teams without bias and a truly genuine collaboration take place? Can the various methods used by all the engineers who maintain file routine code be distilled into 'best practices' or heck a common framework for file saving that will ultimately benefit the  customer? Will egos and politics amongst the engineers allow? I truly hope so.

     

    Thanks,

    Joel Bruner

    Creative Technology Specialist

    Y&R Brands

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 28, 2011 3:41 PM   in reply to Chris Cox

    My whole issue is the file gets deleted from the server if it cant save

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 28, 2011 3:57 PM   in reply to jackjojoj

    If you want Chris I can show you the file being deleted, show you the access log saying the file is deleted. I get the whole using version control, and accept the fact if 2 people have the file open, alter it the last person wins. My problem is files deleteing themselves, and you canned response telling me that this is not happening due to photoshop, and telling me to re-read the thread does't cut it. Saving a file should not delete the file EVER period. If the file doesn't get deleted, why is it gone? Why do the logs say it was deleted? Logs don't lie, and I can reproduce every time. This is not a SAFE save, in fact just the opposite. The few times it happed I was able to retrive the file from backup, but what if the file was worked on after my backup? We have hundred's of thousands of dollars wrapped up in client's projects, are we suppose to tell the client, sorry a photoshop bug wipped out your file and miss deadlines? This is not minor to me.

     

     

    IP 192.168.122.203 - - [27/Apr/2011:17:06:33 -0800] "Delete PacSun_Day_3-2540CON_revFace.tif" 0 0 0

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 28, 2011 4:43 PM   in reply to jackjojoj

    And in response to you snarky reply

     

    "Please read the thread before adding comments.

    (also, this toipic has nothing to do with opening files, so the suggestion about an error message makes zero sense)"

     

    I thought the whole issue is another resource "locking" the file, so how does opening the file while it's not available make no sense to you? (which CS4 seems to do fine by warning you it's open or in use) Reguardless it seems you and your company are taking zero responsability for a major bug. We are not all retarded, I'm sure everyone in here is computer savy.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 28, 2011 7:28 PM   in reply to brunerd

    Joel - we're doing as much safety as we can -- the only thing left is a "post save" check to catch OS bugs. Unfortunately that wouldn't restore the lost file, but would offer you the chance to save again.

     

    As for getting other product teams to use a safe save and aggressive error checking/reporting: we've tried.  Lots of problems in understanding, lots of politics, lots of folks who don't even understand that lost work is a problem...

     

    Yes, we know that the file disappears - and we know that the OS routine is responsible, but we don't know exactly why, or when it will be fixed by Apple.  Photoshop is doing things quite safely, but an OS routine that should help us do things safely is not working.

     

    Previous problems were not due to this particular API, and were always tracked down to the server, or in one isntance to another OS API bug.

     

    It gets quite tiring to have people blaming us and screaming for us to fix things that are beyond our control.

    We've done our part.

    Now start holding your OS vendor to the same standards you hold us to.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 28, 2011 7:29 PM   in reply to jackjojoj

    Jack - please stop posting the same repetitious nonsense and read the existing posts that explain the problem.

     

    Photoshop is not deleting your file.

    Your OS has a bug, and that OS bug is deleting the file.

    Photoshop cannot fix this.

    Apple has to fix this.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 28, 2011 7:59 PM   in reply to jackjojoj

    I thought the whole issue is another resource "locking" the file, so how does opening the file while it's not available make no sense to you?

    Again, it really sounds as if you have not read this or the other thread you posted in.

     

    The issue is saving a file while the OS, Finder or something ELSE may have the file locked.

    It has nothing to do with Photoshop opening the file.

    Photoshop already does warn you if the file is in use by another application when saving -- but the OS bug appears to have issues (maybe timing related) with locks on the file.

     

    We have done our part, and determined that the responsibility in this case is with Apple.

    We cannot fix their OS bugs.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 28, 2011 9:29 PM   in reply to Chris Cox

    In CS4 in the exact same scenario, it throws the error saying it's in use or open. This is totally acceptable. The file deleteing itself is not. Own up to the problem, and solve it. I find it hard to believe it can behave correctly in CS4 and not in CS5.But it's all apple's problem right? And BTW I'm not just reposting nonsense over and over, your response is a load of crap. We spent over 70K for CS5 last year show a little respect to a good customer Chris.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 28, 2011 10:32 PM   in reply to jackjojoj

    You're not even trying to read the existing posts or follow the discussion, are you?

     

    I'm posting the details and the facts.

     

    I'm sorry if you have trouble accepting facts.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 29, 2011 1:18 AM   in reply to Chris Cox

    Chris we should clarify things here a bit:

     

    >> Photoshop is not deleting your file.

    >> Your OS has a bug, and that OS bug is deleting the file.

     

    By "your OS" you are refering to Apple's OSX on the Macintosh running/using PS CS5.

     

    >> Photoshop cannot fix this.

    >> Apple has to fix this.

     

    Then

     

    - why did this pre-existing OSX API bug not cause such trouble with PS CS4 or older?

    - why is this happening only with .PSD files in CS5?

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 29, 2011 2:26 AM   in reply to Foli_RM

    I searched through some of our archived work yesterday and found a bunch of .afpDeleted* files from September, October and November 2008 -- so this was an issue before CS5.

     

    Can we get confirmation from Chris that Adobe have formally submitted this as a bug to Apple?

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 29, 2011 6:16 AM   in reply to Martin Orpen

    I know its not a feature that wows potential cs upgraders (like the ever so useful (ie., useless) content-aware fill tool). But to companies like mine that have 35 photoshop users running a retouching studio off of stock macintoshes with a stock apple server, it is a HUGE problem for us. I understand that adobe doesn't support network saves and copies, but there really isn't any other way for us to get work done in a productive manner. We are thinking of upgrading to Xinet, but apparently they are having the same problem (from this forum). If anybody knows of a systems person or workflow solution that could help us with this problem, we would be glad to pay him/her to come in and look at it or solve it.

     

    Adobe, we are professionals who use your product professionally. Between this and the liquify bug, I have lost a lot of faith in your upgrading builds and testing for professional users, and will wait a very long time before we upgrade to cs6.

     

    Sincerely,

    sean

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 29, 2011 6:38 AM   in reply to Sean C Ross

    To be totally honest open here, even Microsoft's own documentation says they don't support network saves. 

     

    I have seen way too many PowerPoint presentations corrupted by working off a server. 

     

    Networks can be tricky to deal with on file save issues.  We should all know this.  One flaky switch and ruin

    your whole weekend. 

     

    Look this frustrates the hell out of me.  I have 30 designers working on CS5.  Like everyone I want to see

    this thing fixed. 

     

    We are using a Windows 2003 Latest SP service pack using ExtremeZip 7.X (Latest)

    The topology of the network is very simple, all connections are gigabit ethernet.

     

    What I do hope is that Adobe and Apple try to put aside their public differences aka flash and other

    issues and get a solution together that helps us, the customer.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 29, 2011 9:02 AM   in reply to Chris Cox

    So is Adobe's and Apples relationship so estranged, that you cant work with them to figure out why saving can potentially cause deletion? Rather than finger pointing and denial it would be in your best interests to resolve this. Has any one on your team reached out to Apple?  Like I said before, just open the file in Preview and try a save in PS and it happens every time.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 29, 2011 9:10 AM   in reply to jackjojoj

    Lets just say that Adobe and Apple's Relationship hasn't the been the most wonderful over the last few years.

     

    Frankly, I wouldn't lay the blame at anyone's feet on this one because there is enough on both sides that have fed the fires. 

     

    But what I am saying is that they both need work together and work on a fix that will make us the customer happy.

     

    Also I was pointing out that guess what??!!  Adobe isn't the only company that says they don't support network saving.

     

    Look we have been doing it at my company for well over 18 years, and I can count the times on 2 hands and 2 feet that we had a real problem with it.  This year is one of the worse.

     

    But anyone else remember saving a photoshop document and then reopening it only to find white pixel artifacts?

     

    Lets just hope this gets fixed sooner than later....

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 29, 2011 10:10 AM   in reply to Foli_RM

    - why did this pre-existing OSX API bug not cause such trouble with PS CS4 or older?

    Photoshop CS4 was based on the Carbon API, not the Cocoa API that CS5 is based on.

    Photoshop CS4 called slightly different code, but ran into other problems because of that -- and this new API was the solution to those (more frequent) problems.

     

    It isn't only happening on PSD.  We have plenty of complaints about TIFF, PDF, and JPEG with the same symptoms.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 29, 2011 10:12 AM   in reply to jackjojoj

    Has any one on your team reached out to Apple? 

    Yes, repeatedly.

    And yes, I believe we have submitted this as a bug to Apple (but I didn't write the bug report myself, so I can't be 100% positive).

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 29, 2011 10:53 AM   in reply to Chris Cox
    Now start holding your OS vendor to the same standards you hold us to.

    Yes Chris, for sure, I am!

    brunerd.com/blog: Finder’s Nasty Inherited ACL Bug (aka Error -41)

    (This one is on another front however, but yes file system bugs are not foreign to Apple)

     

    Anyway, what about a "safer safe save" where the file is written local then copied to the network share you specify, a checksum is performed, if it fails you get the option to save local (move the local temp file to a user accessible location)?

     

    Here's my cave-man pseudo-code, for illustrative purposes only, the engineers will laugh at me I'm sure, perhaps it is "costly" in the operations it performs and the extra burden it places on the client machine for the temp copy of the file to be saved to (we have some folks working on a 4GB PSB now), but if it was an optional preference for folks that require bullet proof saving I think they'd agree that it'd be worth it!

     

    I see the engineer's point of view as well that API for file save call is the simplest and most straightforward way to accomplish what they want, it's nice because the OS it hides all the details of implementation of the save (method, protocol, etc...), that's the beauty of Cocoa and building un code in to check that it did things right _is_ annoying, but can the parents stop fighting for a minute and think about what's best for the kids in this 21st century of networked offices?

     

    # Cave man simplified save code....

     

    function saveDocument

    {

    // save the file local first

    saveLocal(&data, localTempFile);

    //put on server with temp name keeping original file untouched

    copyTempToDestination(localTempFile, remoteTempFile)

     

    #make sure they are the same byte for byte

    if (checkSum(localTempFile) != checkSum(remoteTempFile))

    then
         // it failed offer to move localTempFile to a user accessible location

         SaveErrorRecoveryDialog("Network save failed (destination file unaffected). Save a local copy to another location?)", localTempFile)

    else

         //checksums match yay! overwrite existing file on server

         // rename existing file with a temp name, then rename the new copy with destination name

         renameFile(remoteFileName, existingFileTempName)

         moveTempIntoPlace(remoteTempFile, remoteFile)

     

         if ( moveResult = GOOD )

         then

              Dialog("Wow I just successfully saved to a network volume?! Who'da thunk it!")

              delete(existingFileTempName)

         else if ( moveResult = BAD )

              //move existing file back into place

              rename(existingFileTempName, remoteFileName)

              Dialog("Dang something went wrong! Network copy unaffected. Save a copy to another location (locally)?", localTempFile)      

         end if

    end if
    }

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 29, 2011 12:15 PM   in reply to brunerd

    We don't want to read the whole file back to do a checksum, because that could take as long as saving did.

    But we are looking into adding additional safety checks, on the evidence, er, I mean assumption that OS APIs and file servers can silently fail when they shouldn't.

     

     

    In this case, the API is needed to preserve permissions, and avoid several other problems that occured in previous versions (and happened more often than this issue).

     

    But everytime we add more safety, more checks, more code that should improve reilability -- OS and server software vendors find other ways to break it.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 29, 2011 12:39 PM   in reply to Chris Cox

    Chris Cox wrote:

     

    ...please stop posting the same repetitious nonsense and read the existing posts that explain the problem...

     

    Few people like to wade through this many posts in a 3-page discussion. It is no surprise that people are not reading previous posts.

     

    This thread is clearly a keyword lightning rod for search engines. Everyone is coming to this thread because there is no authoritative article discussing this error message on kb2.adobe.com.

     

    Could a clear, single-page kb article be added that would be more easily digested by the masses?

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 29, 2011 1:18 PM   in reply to Marian Driscoll

    Not without angering certain OS vendors beyond what I've already done :-(


     
    |
    Mark as:
  • Currently Being Moderated
    Apr 29, 2011 1:44 PM   in reply to Chris Cox

    I see the 'diplomacy' demonstrated in the "Reason" section of this article:

    http://kb2.adobe.com/cps/403/kb403815.html

     

     

    apple.png

    (This image is a joke but the lack of a posted reason on the real page is the real sign of diplomacy.)

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 9, 2011 12:20 PM   in reply to sean-gloss

    Has anyone tried playing with the following AFP settings in Xinet to see if that has an impact?  I wonder what the option for "No special treatment" would do for the newer versions of OSX if anything.

    Screen shot 2011-08-09 at 1.12.59 PM.pngScreen shot 2011-08-09 at 1.13.08 PM.png

     

    We recently have run into this with one user on 10.6.5 runing CS5 using Xinet on IBM servers with RedHat Enterprise installed.  Client machines have dual port aggregated ethernet running to a switch that has a 10 GIG uplink to the server. 

     

    If I do a terminal to the share, the .afpdeletedXXXXXX file is created and as mentioned before a mv command to a new file name brings the file back "from its "disappearance" according to the user.  Only part that Apple is involved in is the client.

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 9, 2011 2:06 PM   in reply to sean-gloss

    So we recentrly upgraded Xinet to 16.06, I'll check with our Xinet admin (out today) what the "dot filename" treatment setting is.

    It would be interesting if it was Xinet causing this by trying to apply the invisible setting to the file while other operations in PS were trying to access it. Although why would you call a temp file .afpDeleted is beyond me...

     

    Anyway, so we are on FullPress 16.06, running Photoshop CS5 12.0.4, on a new iMac 27" with 10.6.8 v1.1 (yes, it shipped with Snow Leopard thank god) and we are now graced with a new .afpDeleted error message! The user started using PS CS5 yesterday on his MacPro and had this happen, then today on his new iMac 27" - the following is a screen shot of the error with the Terminal in the target directory, showing the .afpDeleted file

     

    PS and Terminal.png

    Dialog text:

    Error 8800: General Photoshop error occured. This functionality may not be available in this version of Photoshop.

    - Could not save ".afpDeletedxxxxxxxxx" because write access was not granted.

    Line: 54

    ->

     

    When our Xinet admin gets back, we might try altering the "Filenames that start with period (.)" to "No special treatment (may crash ancient Mac clients)"

    Since every client we have here is now 10.6 there are no ancient Macs...

     

    Anyway funny, I was just about to revive this thread just this morning before the new post, nice one mccolo

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 9, 2011 3:24 PM   in reply to sean-gloss

    brunerd

     

    We are still on FullPress 16.05 without the database turned on our WIP.  The strange thing is, it appears from your screen shot, as from the ones I have seen in terminal, it isn't a perms issue, because they have access. So I dont understand where Photoshop is getting the error message and why it thinks it is a write issue if all the settings are open.  Perms was one of the main reasons we went to Linux instead of Apple.

     

    More tech info to rule out io errors due to speed.

     

    The machine is an 8core Mac Pro with 16GB of RAM, a 1TB scratch and 512GB hard drive, with dual ethernet aggregated to a layer 3 switch with a 10gig backbone. The Server has 4 10 gig uplinks to an IBM server with 96 processors, 256GB of RAM and 15K drives on a fiber channel raid through a SAN. This is our only user TESTING Photoshop CS5, which is why no other users are having this issues.  Perhaps it is related to the ACL issue apple has worsened in SnowLeopard with duplicate ACLs appearing all over the place depending on how nested the folder is = the number of ACLs on the file. Supposedly that is fixed in Lion, but I think its just another ploy to buy new hardware. Perhaps we will just have to stop buying Photoshop, move to Linux and start using open source software and the old school retouching techniques that always seemed to work. 

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 9, 2011 3:38 PM   in reply to Chris Cox

    Chris, I ran into the same situation this a.m. Desktop Leopard and new MacBook Pro. Shared a file for screen saver when setting up last week. Opened

    one of the jpgs on the MBP to make a minor color adjustment and hit save. Got the "could not save because message" along with instructions to

    unlock or open the "get info" for the file and check permissions.  When I opened the file, sure enough, the permissions related to my MBP and no permissions were active for read or right. I unlocked as admin, added read and write and all was well. I did not loose the file after my first failed attempt. I checked the file on my desk top and sure enough, the same situation.  Here is the deal.  The original screen saver file was created on my old IMac, Tiger, that died a few months ago.  My admin name on IMac was "Susy Smith". My admin name on my new desk top, Leopard, is "Susy J Smith". Admin name on MBP, Snow Kitty, is "Susy J. Smith".  It appears CS5 reads the permissions and if a file was created on another machine with different permissions, the permissions will show on the file for the current computer but will not have read and write activated. It will give this message and require you to apply proper permissions.  It was required for all 7 jpgs in the file in question. A royal pain. The only answer if you use multiple machines appears to involve making sure read and write permissions have an identical common identity for read and write on all of the machines.  I have not run into this ever before and did not switch to CS4 to see if this applies there but it likely does.  I did not have the file disappear however when it failed to save the first time.  I hope this helps a little.

     

    asu_chic

     
    |
    Mark as:
1 2 3 4 5 ... 10 Previous Next
Actions

More Like This

  • Retrieving data ...

Bookmarked By (4)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points