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 ... 10 Previous Next
  • Currently Being Moderated
    Feb 3, 2011 2:31 AM   in reply to Chris Cox

    Since I have next to 10TB of photos and videos to work with I'm keeping my stuff on a raid system in my basement. The raid is connected to a Mac Pro (running OS 10.5) which shares the volume via afp.

    I'm the only user on my "network" using the files from my desktop MacPro (currently using OS 10.6). Ever since I've been running this setup (about three years) I keep having this "write access not granted"-problem when using Photoshop's "save as"-command.

    This applies to Photoshop CS3 and CS5 (I skipped CS4) as well as all OS-combinations from, say, 10.3 on desktop and server. No other software I'm running (like InDesign, Final Cut, Logic, whatever) ever gave me this error.

    Typically, when I start a Photoshop session saving works a couple of times when I save various iterations of a file under different file names. Then, once the problem pops up Photoshop will refuse to write any new files to the server and I have to resort to saving to a local volume. Restarting Photoshop usually allows me a new couple of saves.

    I can definitely see this behavior on a daily basis.

    As I can exclude any other users from accessing the file or browsing the directory (as earlier posts suggest) the only other processes that might interfere might be open finder windows on my own desktop or background activities such as Spotlight indexing or whatever.

    Someone suggested such a problem may be related to a bug in the raid file system. I know the possibilities are endless. Still, it's a fact that somehow only Phototshop managed to cough on whatever problem is behind this.

    I think you are saying that Photoshop calls Cocoa APIs that InDesign probably doesn't?

    Well, if that particular API is buggy on Apple's side, why are you insisting on using it if other solutions exist that seem to work?

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 3, 2011 3:54 AM   in reply to Widowsoft

    Yeah, the permissions issue is confusing because Photoshop *should* be able to overwrite the hidden temporary file anyway... all it should do is warn you that the dot prefix isn't a good idea.

     

    What exactly were you seeing with the ACLs?

     

    All of the .afpDeleted* files that litter our server have identical permissions to the ordinary working images in the same folders.

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 3, 2011 10:25 AM   in reply to j. scriba

    Well, if that particular API is buggy on Apple's side, why are you insisting on using it if other solutions exist that seem to work?

    Prior to Photoshop CS5, Photoshop used the older Carbon APIs the same as InDesign, Illustrator, etc.

    Photoshop CS5 now uses the Cocoa APIs and updated several APIs for handling file permissions and parts of the safe save copy mechanism.

    The fact that you've had the same problem with Cocoa and Carbon versions would indicate that the fault is more likely in the server protocol or OS.

     

    And if we could ever get this to fail on our own servers, we'd have more information.

    But we have never gotten this to happen except with some third party servers that had a clear bug in them.

     

    We'll do more testing and see what we can find....

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 3, 2011 1:12 PM   in reply to Widowsoft

    Hi Widowsoft.

     

    We had this error happen again today so I asked the operator to hold off responding to the warning dialogue and checked the permissions from the Mac that they were saving to.

     

    Checking the directory using ls -le I found ACLs appearing on all the files and folders in the directory. I wasn't expecting any because we're not actively setting them.

     

    Later checks on the same directory show no ACLs.

     

    I checked the Mac and find that Time Machine is set to back up the drive that is being saved to. I couldn't see any other process running that would be likely to impose ACLs -- so maybe Time Machine is the culprit?

     

    It's the same drive that I tested with 1,500 saves last night without any errors so maybe the timing of the save is critical and this is why it seems random -- and that some users can hit save again and it works while others are unable to save at all?

     

    Got any suggestions as to how we can isolate this problem? The only time I've had to tinker with ACLs was to lock down Joomla on our Linux web server...

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 3, 2011 1:51 PM   in reply to Martin Orpen

    Yes, it's possible that TimeMachine is involved.

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 3, 2011 2:35 PM   in reply to Chris Cox

    Hi Chris,

     

    Im having a similar problem. My studio is set up with 30 retouchers using Photoshop CS5 and Snow Leopard and around the same number of photographers with the same OS and a mix between CS5 and CS2 all Connecting to a windos server via SMB.

    We work on approximately 1500 files per day and only ever encountered this error message rarely. Over the past few days it's been happening constantly. Our IT department have no idea how to solve it or create a workaround. Other than to say we'll be switching to a mac server and connecting via AFP at some point soon which will solve the problem?

     

    Three things that are confusing me:

     

    • Why is it that this error has started occuring so frequently, is there anything I can check?

     

    • Why am I able to open up a file, make adjustments, then subsequently have other retouchers do the same things while the file is open and the message doesnt appear, this seems like an inconsistent error..

     

    • We can detect which user is supposed to have the file open, but more often than not when we look at the machine, the file was closed some time earlier. Is this caused by the file lock taking longer to release due to the SMB connection?

     

    Is there any work around you can suggest or way to stop this happening, because its having a massive impact on the ability to hit deadlines and causing all sorts of workflow and DAM issues.

     

    Many Thanks

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 3, 2011 2:45 PM   in reply to C-S-S

    "write access not granted" warnings are just part of what we're talking about here.

     

    That usually means that some other user, or process, has the file open on the server.

     

    Opening a file doesn't lock the file -- we only use the file while reading it into memory, then let go.

    The file should only ever be locked while actively reading or writing it -- but some other applications keep the file open and locked by mistake.

    And some OS utilities (AV, thumbnailing, backup utils) can have the file open longer than expected.

     

    We don't know the cause.  It's just an error returned by the OS, which we pass along to the user.

    We have no way to know what process, user, etc. has the file open -- just that we could not get write access because the file was busy.

     

    Running a clean server helps (get rid of the extra processes).

    But if there is a bug in the OS file protocol stack - that's harder to avoid.

     

    And, again, this sort of problem is one of the reasons we say not to work from a server directly.

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 3, 2011 2:55 PM   in reply to Chris Cox

    Thanks for the response.

     

    Am still slightly confused as to why im able to open a file up, then others do the same and save over the image whilst its still open on my screen. I'd expect it to be an open/shut issue; where Someone has the file open, you cant save over it? From the sounds of it this isn't the case?

     

    I realize that Adobe has never supported working off servers directly, but with a workflow dealing with anywhere up to 8000 files per week and the need for constant open access to the files, is there an alternative you can suggest?

     

    Thanks again

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 3, 2011 3:07 PM   in reply to C-S-S

    The file is only busy in between you hitting the "open" button and the document appearing on the screen. After that, you are working on something in memory and the file is not being used until you hit "save".  The key is: the document in memory and on disk are 2 different things, only related by history (and I don't mean Photoshop's history feature).   Otherwise you would never be able to get thumbnails, backups, or multi-user situations to work at all.  We do a lot of testing to make sure that we hold the files open as short a time as possible.

     

     

    Copying the file to your local machine, then copying it back is much, much safer.

    Or using a file management system of some sort (asset management, SCM, etc.).

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 3, 2011 3:32 PM   in reply to Chris Cox

    So theoretically, The only way for this error to be blamed on two machines having the file open at the same time, is if you try and save whilst someone else is trying to open or save. Or an application other than photoshop i.e C1 or finder is using the file.

    The fact that we're seeing this error about 300 times a day must be due to a network issue as its very unlikely for two people to be performing the same actions on the same files at the same time..

     

    Another error that often appears before this one; makes refernce to the disk image beig changed since the file was opened, although nobody else has worked on the file.. Very random!

     

    Sorry for all the questions, essentially im on Adobe's side, but my IT department are saying photoshop is the problem not the network..

     

    Thanks

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 3, 2011 4:14 PM   in reply to C-S-S

    Two machines trying to open or save at the same time is how we normally expect this to happen.

     

    Other applications sometimes have a bug that holds the file open too long.

     

    Seeing it that often probably means an issue on the server, or with the network protocol code in the OS.

     

    Another error that often appears before this one; makes refernce to the disk image beig changed since the file was opened, although nobody else has worked on the file.. Very random!

    If it hasn't been touched, then that means it was modified on the server, or that something is returning the wrong date/time stamp for the file (server or OS code).

     

    Sorry for all the questions, essentially im on Adobe's side, but my IT department are saying photoshop is the problem not the network..

    Lol. Your IT department needs a bit more experience.

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 4, 2011 1:34 AM   in reply to C-S-S

    Our IT department have no idea how to solve it or create a workaround. Other than to say we'll be switching to a mac server and connecting via AFP at some point soon which will solve the problem?

    AFP & Mac server won't help.

    As you can see in the other posts the issue even happens when a single Mac user accesses a Mac sharing volume.

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 4, 2011 1:47 AM   in reply to Chris Cox

    Copying the file to your local machine, then copying it back is much, much safer.

    I can hardly believe you are saying this.

    I'm sure you're aware of the fact that these days people work on thousands of pictures a day in a collaborative environment.

    No matter who's fault this is, the fact is that no  other program I use exhibits this issue.

     

    The fact that you've had the same problem with Cocoa and Carbon versions would indicate that the fault is more likely in the server protocol or OS.

    You're probably right that something is wrong with my server. Still, no other program I use ever exhibits this problem.

    The fact that numerous other users in various different environments suffer from this issue makes me wonder if your approach is adequate.

    If there are tons of customers out there in a world with imperfect server structures - wouldn't it make sense to use a file handling procedure that deals with these imperfections?

    Obviously most other programs can deal with it, Photoshop can't.

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 4, 2011 10:14 AM   in reply to j. scriba

    Still, no other program I use ever exhibits this problem.

    Most other applications don't do as much error checking and reporting as Photoshop.   Photoshop is telling you about errors that most other applications would simply ignore.

     

    It's not a huge number of customers with server problems -- many people are using network servers without any such problems.

     

    And our file handling is supposed to deal with this sort of problem, but somehow an OS or server API is not doing the right thing.

    Yet when we test it on our huge mix of systems, everything works fine.

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 4, 2011 10:34 AM   in reply to j. scriba

    I have to agree with j. scriba and others who point out that this problem or similar errors occur across different versions of photoshop and different kinds of servers, but not at all with any other programs. I've worked in multiple shops over the last 20 years and it's always been gospel that "you can't work off the server" with Photoshop, but somehow this is never a problem with any other program saving files.

     

    It seems exceedingly odd that no one at Adobe has ever been able to reproduce this problem, and yet the official recommendation is to not work off servers and to only work locally. Obviously this has been going on for years and Adobe has probably heard thousands of complaints, and yet never able to reproduce it. That's just some kind of amazing luck. I'm sure it must have occurred to someone at some point to go out into the field and see if they could figure out why it happens to so many users in so many different environments, right?

     

    Let's think: why does this never happen with InDesign or Illustrator files? Why can't Photoshop emulate these other widely used Adobe products in the way it saves files? Clearly it is doing something different, but why? What is so special about Photoshop's save protocol? Sure, it may very well be a "bug" in all these server configurations, but the fact that it keeps recurring over the years would indicate that there is SOMETHING about how Photoshop saves files that's, well, a little weird. Right? And why exactly can't Adobe change it?

     

    Here's an analogy. We release jobs to printers for our clients all the time, typically InDesign packages. We spend a lot of time preflighting and checking to make sure everything is in order. Sometimes things don't print correctly, and sometimes it is our fault and sometimes it is the printer's fault. Either way the client isn't happy. Even when it is clearly not our fault, we examine our workflow to see if we could make changes that would reduce the chances of errors. We change our "product" to accommodate other vendors' "bugs". I guess if we were basically the only prepress vendor in the world (or at least the dominant one), we could just say "it's the other guy's fault, deal with it". But even then, we'd rather have happy clients. Wouldn't Adobe rather have happy customers?

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 4, 2011 11:04 AM   in reply to Todd Shirley

    It seems exceedingly odd that no one at Adobe has ever been able to reproduce this problem, and yet the official recommendation is to not work off servers and to only work locally

    We know that server problems exist.

    We've seen customer having problems, and how long it takes them to find the cause and fix the network or server issues.

    So we should say: "In a perfect world you can work on a network server, but your world probably isn't perfect, so don't do it or you'll end up regretting it."

     

    And yes, we've only been able to reproduce similar issues with servers that had a known bug in them (mostly third party).

     

    Yeah, we've gone out in the field, visited customers -- and found servers with known problems (old versions, misconfigured, faulty hardware, etc.).  Once we found a new bug in AppleShare (and Apple got a patch out pretty quickly).  Once those problems were removed, everything worked reliably.

     

    ID and AI don't do as much error checking.  We know that.  Many other applications don't even try to do a safe save.

    What does Photoshop do differently: check for errors, tell the user about errors, and do a safe save to minimize file loss.

     

    Oh, and we have changed our saving code several times over the years -- yet the errors persist on some servers (but never ours).

     

    Many, many times we have worked around OS and server bugs.  But we have to know about the bug, and it has to be something we can work around.  You can't always work around the OS bugs (like low level memory and file IO code).  In this case we can't work around what we don't know about and can't reproduce.

     

    We are trying to do the right thing for our customers, otherwise we would have given up on this issue a long time ago.

    Think about it: you keep reporting a problem that looks like a bad server config, we keep testing and never finding a problem -- shouldn't we have concluded that it's all in your server and given up?

     

    Again: we are working hard to do the right thing for customers.

    As of right now, we have no evidence whatsoever of a bug in Photoshop.

    But we are continuing to investigate.

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 4, 2011 11:15 AM   in reply to Chris Cox

    Chris Cox wrote:

     

    It's not a huge number of customers with server problems -- many people are using network servers without any such problems.

     

     

    I think the correct way to put it is"not a huge number of customers REPORT server problems". Like many in this list, I've been doing this for a long time, and every environment I've worked in and every peer or IT person I've ever spoke to about this has encountered similar problems "working off the server" with Photoshop. Most companies just do what we do and what Adobe recommends: copy files local to work on them and then copy them back to the server when done. We don't waste time reporting known bugs to Adobe. (or writing lengthy rants in forums )

     

     

    ID and AI don't do as much error checking.  We know that.  Many other applications don't even try to do a safe save.

    What does Photoshop do differently: check for errors, tell the user about errors, and do a safe save to minimize file loss.

     

    Oh, and we have changed our saving code several times over the years -- yet the errors persist on some servers (but never ours).

     

    OK, why don't these other Adobe products do much error checking? And you call it a "safe save", but many in this thread report LOSING data. How is it that doing MORE error checking and doing SAFE saves results in data loss, but ID and AI do neither and users experience no data loss or problems?

     

    Message was edited by: Todd Shirley

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 4, 2011 11:15 AM   in reply to Todd Shirley

    it seems like Adobe should send an engineer out into the real world to one of the thousands of businesses who experience this problem on a regular basis and try to figure out what they are doing wrong.

    We have, repeatedly.  See my previous post.

    We've even brought a few servers in house to analyze - same results: server issue.

     

    I think the correct way to put it is"not a huge number of customers REPORT server problems".

    Which is why we ask customers how they work, and if they have experienced any problems.  Many do work directly off the server, without problems.

    Others have problems with the server, then solve the server issue and continue to work without problems.

     

     

    considering how this server issue has been a known problem for at least 10 years

    That's just it:  this is not a known bug in Photoshop.

    The only known problem is "networks and servers are difficult to setup, maintain and troubleshoot".

     

    If there is a bug, we'd love to find it and solve it.  But we've been chasing this sort of problem for years, and always finding the problem is external to Photoshop.

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 4, 2011 11:40 AM   in reply to Chris Cox

    Chris, it would be helpful to me if you could explain exactly how the Photoshop Save works.

     

    I cannot understand how any application would end up reporting that it couldn't write a temporary file -- when it already has.

     

    Or how, if it can't write the temporary file, it still manages to allow or cause the original file to be deleted?

     

    Photoshop *is* exhibiting peculiar behaviour here no matter what the underlying cause of the problem is...

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 4, 2011 12:09 PM   in reply to Martin Orpen

    Safe save:

    write to a temporary file

    swap/replace the temporary with the original

     

     

     

    The error seems to occur when moving the temporary to replace the original file.

     

    The only way the original could be deleted is if the OS or server mangles the swap/replace operation.

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 4, 2011 2:55 PM   in reply to Chris Cox

    ID and AI don't do as much error checking.  We know that.  Many other applications don't even try to do a safe save.

    What does Photoshop do differently: check for errors, tell the user about errors, and do a safe save to minimize file loss.

     

    May I suggest that you simply add an option in Photoshop file handling settings like:

    a) use safe saving (may block saving with faulty servers)

    b) use standard saving (may lead to file loss with faulty servers)

     

    This way, you can still tell users that whatever problem they encounter will be their server's problem and you strongly suggest working off local drives.

    And many users will opt for a mechanism that so far has worked great for them in ID, AI and other software.

    After all, you let users even chose tile sizes, cache levels and other fancy stuff under Photoshop's hood. Why not such a fundamental setting?

    You won't get any more complaints from people who can't take proper care of their systems, and we get a less elegant solution that simply works. Everybody wins, right?

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 4, 2011 3:37 PM   in reply to j. scriba

    Without reproduceable cases to test - we have no idea if that would work.

    It all depends on what is wrong with the APIs or servers.

     

     

    ID and AI probably aren't working - they just aren't reporting the error (and loss of your files) to you.

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 5, 2011 1:30 AM   in reply to Chris Cox

    ID and AI probably aren't working - they just aren't reporting the error (and loss of your files) to you.

     

    Em.... Chris, somehow this discussion is turning weird.

    I was suggesting you implemented (as an option for Photohop users) the exact same file handling that InDesign and others of your applications are using.

    I suggest that you test it to the same level of confidence that you are using in those other products and give users the choice of whether they want Photoshop to run the extra mile of super-safe saving (that may cause their faulty systems to prevent saving at all) or do like the others do (at their own risk).

     

    Are you saying that InDesign is a faulty product that keeps losing files?

    Are you saying that everybody who is reporting this Photoshop-problem is probably losing files with their other software?

    Are you saying that I'm too (insert a nicer word for "stupid") to realize that I'm constantly losing files, even though I'm pretty sure I've never lost  a file in my setup?

     

    I'm actually pretty paranoid about my data. That's the whole point of saving to a remote raid system.

    I feel that the process of Photoshop forcing me to copy workfiles to local drives and keep track of which version is replaced by which introduces an element of human error that much more prone to accidentally losing an edited file.

    Why do you insist of forcing an extra level of file handling security on Photoshop users if they are content with how all of their other applications are handling this?

    If I had the choice of disabling "safe saving" (which might be on by default) and then lose a file it's my choice and my system that screws up.

    Why can't I make this choice?

    Why do you feel the need to tell your users that what they normally do with their other software (and Adobe's other products) is a wrong way of doing things and that some of us are driven crazy by Photoshop's file handling only for their own good?

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 5, 2011 11:08 AM   in reply to j. scriba

    I was suggesting you implemented (as an option for Photohop users) the exact same file handling that InDesign and others of your applications are using.

    How would it help to change our code from "safe and telling you about problems" to "unsafe and not reporting errors"?

    Then people would lose their documents and never know that a problem happened.

    That's not something we would even consider!

     

    If there is a problem in Photoshop, we'll fix it.

    If there is a bug in an OS routine, we'll file a bug and try to get it fixed.

    But we will not intentionally damage our software just to let you unknowingly lose work!

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 5, 2011 2:12 PM   in reply to Chris Cox

    To summarize:  1.Two of Adobe's flagship products, InDesign and Illustrator, save files in a way that is "unsafe and not reporting errors" which leads to a situation where "people would lose their documents and never know that a problem happened."   2. As far as we can tell, Illustrator & InDesign users are completely unaware of this major fault in these products and are somehow ignorant of the fact that they are losing data on faulty servers. These users live in a state of ignorant bliss where they never notice data loss or report saving errors to Adobe.  3. Photoshop saves files in a way that is "safe and telling you about problems" which is superior to the way InDesign and Illustrator save files.  4. For years, Photoshop users have been complaining about difficulty saving files to servers and occasional data loss and corruption, even though Photoshop saves files in a way that is safer and better.  5. For some reason, Adobe doesn't want to implement the safe and superior file saving method with InDesign or Illustrator, nor give Photoshop users the option to use the inferior (but widely used and well liked) saving method used by InDesign and Illustrator.  Is that about it? What am I missing here?

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 5, 2011 2:25 PM   in reply to Chris Cox

    >> I was suggesting you implemented (as an option for Photohop users) 

    >> the exact same file handling that InDesign and others of your 

    >> applications are using.

    How would it help to change our code from "safe and telling you 

    about problems" to "unsafe and not reporting errors"?

    That's not something we would even consider!

     

    I see, so InDesign, Illustrator etc. are broken products.

    Amazing that Adobe is very happy charging substantial amounts of money 

    for them and a large number of customers are happy buying and using 

    them.

     

    Suppose there was car that ran 200mph  smoothly but would 

    automatically perform a screaming emergency brake maneuver once its 

    radar detected a pothole in the street.

    You would like to drive through potholes just like all the other cars 

    on the road do and ask the car maker to fit that radar with a switch 

    so you can disable it on the less-than-perfect roads you need to drive 

    on.

    The car designer would say: There's nothing wrong with the car and 

    potholes are nothing we can fix. We can't let you go without the 

    radar, you might have an accident. We suggest you drive on perfect 

    roads only.

    Would you appreciate that attitude?

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 5, 2011 3:29 PM   in reply to Chris Cox

    So the .afpDeleted* file that is all that remains your cherished image on the remote disk is what exactly?

     

    If it is the temporary file, then it *has* been written -- so the dialogue box is incorrect.

     

    If it is the deleted original then why does the dialogue box show the temporary file name and not the original file name?

     

    If you can't recreate this issue in-house then perhaps it might be worthwhile giving customers who are suffering a modified version of PS which dumps more information to the dialogue box or console during the Save operation?

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 5, 2011 6:13 PM   in reply to Todd Shirley

    Each product is a separate team.

    And no matter how many times we request something, suggest something, write bugs against other products, etc. - we cannot make those other teams do anything (no matter how badly they mess up).

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 5, 2011 6:15 PM   in reply to Martin Orpen

    So the .afpDeleted* file that is all that remains your cherished image on the remote disk is what exactly?

    We don't know.

    Again, we've never been able to reproduce the problem.

     

    We are already trying to connect with some customers experiencing this problem to get them an instrumented copy of Photoshop.

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 8, 2011 7:06 AM   in reply to Chris Cox

    The problem has occurred again today so I can now confirm that the .afpDeleted* file is the original image.

     

    I can also confirm that Time Machine wasn't involved as this happened around 40 minutes after the last backup.

     

    Again, I don't get how this error can be blamed entirely on the OS?

     

    There are no other hidden or temporary files at this location so it appears that Photoshop is NOT safe saving *anything* (or is both saving AND the deleting the new data) before flagging the original file for deletion.

     

    And how on earth does the new name of the original file, now flagged for deletion, end up in the warning dialogue in PS?

     

    Confusing

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 8, 2011 10:30 AM   in reply to Martin Orpen

    The problem has occurred again today so I can now confirm that the .afpDeleted* file is the original image.

    That tells us something.  That means that the OS API to replace the original file failed partway through.

    (otherwise the original would still be in place)

     

     

    Again: if the OS and server were working correctly, this should be impossible.

    Photoshop wrote to a temporary, called the OS to replace the original with the temporary, and the OS failed partway through that operation.

     

    If the save failed at points where Photoshop has control then the original would be intact, both files would be there, or the newly saved file would be there.

     

     

    OK, now we have more information for our investigation - thank you.

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 21, 2011 10:04 AM   in reply to sean-gloss

    Yep...

     

    Getting the exact same thing here at my office...

     

    Just had one of the production guys in my office ******** about it.

     

    OS 10.5.8

     

    Photoshop CS 5

     

    Working off desktop, not the servers... also if working off the server its windows 2003, extremezip IP 7XX (latest)

     

    One of the interesting things is that when he gets the error... it does it for every file.. even a new one he creates.

     

    Fun fun fun fun... NOT

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 21, 2011 10:11 AM   in reply to JohnKGibson

    If you get that error saving to the desktop, then you have a very different problem from the server issue being discussed here.

     

    Working locally, that would indicate a permissions problem or something has corrupted the state of the OS or memory.

    As usual: try disabling all third party plugins, all haxies and utilities that might interfere with Photoshop (especially file system utilities).

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 23, 2011 4:22 PM   in reply to brunerd

    I too am experiencing this with Xinet.

     

    Are you serving Xinet of a MAC server, I cannot remember...

     

    My current theory has to do with POSIX permissions. If you are managing server access using ACLS from other apps, inheritance is like CRAP on OSX for directories, even with a mask. File inheritance works great, which causes an issue with who owns a file once a new directory is added with incorrect permissions.

     

    This is a theory that I am testing against right now.

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 23, 2011 5:31 PM   in reply to augur165

    Actually we are using IBM servers running Linux for Xinet and before that SGI Irix

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 23, 2011 6:33 PM   in reply to brunerd

    Do you have this problem with servers that aren't running Xinet?

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 1, 2011 9:48 AM   in reply to sean-gloss

    On our setup, we think (tentatively) that we have found the culprit.

     

    We turned off the DFS service on the server (which I believe is an SBS 2003... I'm just the Mac guy, so I don't deal with the PC servers directly).

     

    We were only using the replication feature of DFS.

     

    We also use ExtremeZ-IP and we had this save issue with both the older and the newest ExtremeZ-IP.

     

    As soon as we turned off DFS/Replication, the server was more responsive and these errors stopped appearing.

     

    The issue originally appeared for us as soon as we upgraded to Snow Leopard and Adobe CS5.

     

    It's been about 4 weeks since we made that change, and so far so good (we hope!).

     

    Hope that helps someone...

    -Rob Steward

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 8, 2011 4:35 PM   in reply to sean-gloss

    Problem has recently surfaced for us with upgrade to CS5.

     

    OSX10.6.5 iMac and Xenon clients with Xserve 10.5.8 and Xsans.
    Active directory with about 7 acls in use (and sometimes many more due to 10.6.4/6 Finder bug that duplicates acls on folder copy).
    Managed preferences for OS clients.

     

    get access error with name of temp file and original psd or eps on server is gone.
    multiple save attempts fail. save-as works.

     

    Chris, really appreciate your commitment and comments on the design philosophy behind PSD's saves.
    Moving to Cocoa APIs is brave but needed as Carbon's days are doubtless numbered.

     

    If I can offer any further info to help get to the root of this issue in CS5 or if you would be interested in us testing with a special version of PS, let me know.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 16, 2011 10:02 AM   in reply to Chris Cox

    okay... just wrote a lengthy reply and Adobe forums responded with "Page not found" and pressing back in browser history returned me to a blank reply slate... What an awful way to handle forms... Now I shall to remember to Cmd+A -> Cmd+C before submitting.

     

    Anyways... a short summary:

    We've started seeing this on one workstation this week. To me it looks like it may have something to do with permissions on the PS executable folder vs user system rights vs user share rights. In short ACL conflicts.

     

    I'll be digging into the ACLs in the morning.

    Do you want us to run a debug logging PS CS5? It would also be possible for you to get a peak via remote if you'd like some real world hands on with the error

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 18, 2011 8:56 AM   in reply to Martin Orpen

    Like Martin, I too have a team of designers and production staff who would be willing to try a version of Photoshop with additional debug code in hopes it might help understand this issue.  We're seeing it on CS5, running on OS X.6.5 and X.6.6 on MacBookPros and Quad core Xenons, writing to an Xserve running 10.5.8, via Apple native AFP.

     

    One thing that caught my eye in this coversation is the idea that backup software could have the file open and cause a conflict (#46).  I use CrashPlanPro for backups, which will be backing up changed files multiple times/day.

     

    To others seeing this: what backup software are you using, and could it potentially have a file marked as open while the backup occurs?  Might NOT having backup software intalled on Adobe's test servers be part of why they've not been able to reproduce this?

     
    |
    Mark as:
1 2 3 4 ... 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