Previous 1 2 3 4 5 6 Next 190 Replies Latest reply: Jul 9, 2008 2:23 PM by trouspinette Go to original post
  • graylit Level 1 (0 points)
    Don't know if this will work for all of them, but I was having the same problem and was able to open the corrupted psd with GIMP for Mac. I tried saving down as a psd again, but it was still corrupt. At least you'll have some level of control and be able to save something.

    Hope this helps.
  • Bill Raab Level 1 (25 points)
    I too am experiencing this problem. I needed to resolve our problem with printing to Xerox Phaser 7750s which caused them to reboot or crash so I jumped all over this update thinking it was the holy grail of 10.5. Sadly while I think it may have fixed my printing issues I can better deal with printers dropping offline then I can with Photoshop work being lost. I have instructed our users to copy locally but we have not done that for years.
  • Alastair Houghton Level 1 (10 points)
    Terry Jackson1 wrote:
    Working directly on files on the server is bad practice....


    Real server set-ups have UPSs and RAID and have a much smaller chance of anything nasty happening than a normal desktop system.

    The only argument for working on files locally is where the files are huge and/or you aren’t using gigabit Ethernet.

    Terry Jackson1 wrote:
    think of it this way, say you get a surge or spike and the server takes a hit
    while your in the middle of airbrushing that photo? Do you think it will
    be recoverable after that?

    How is this different from the situation where your local machine takes a hit while you’re in the middle of airbrushing your photo? (Answer: it isn’t, except that the latter is much more likely to happen because you probably aren’t attached to a whacking great UPS.)

    The only way to keep your data properly safe is to take regular back-ups anyway, so this is a total non-argument.

    And from the perspective of a software developer, network drives are basically the same as other drives on the machine. 99% of problems I’ve seen are caused by unwarranted assumptions (e.g. that the temporary folder is on the same filesystem, or that some bit of the filesystem is case-insensitive). If software malfunctions when used with a network home, that is a bug (though admittedly in some cases it may be a bug in part of Mac OS X). It doesn’t matter how much the developer’s support staff would like to characterise it as an “unsupported configuration” (doing that is akin to Boeing telling airlines that thanks to a problem with their guidance system, flying west is unsupported and that all Boeing pilots should work around the issue by flying east instead—i.e. it’s silly).
  • Alastair Houghton Level 1 (10 points)
    Ben R wrote:
    Officially, Adobe have never supported saving over a network.

    Where did you find that information? Since, barring bugs in OS X (which do occasionally happen), the only differences between saving on a network volume and a local volume are things that developers shouldn’t be making assumptions about anyway, this seems an indefensible position to adopt.

    Adobe’s support staff may wish that they could write it off as “unsupported”, but as I said in a previous post, that’s like Boeing telling all airlines they can only fly east due to a bug in their guidance system. Sure, you can still get the job done, but it’s a ridiculous limitation.
  • backfliprabbit Level 1 (0 points)
    The problem won't happen the first time you save a psd to a server. It only happens when you open that file from the server and save it again.

    so instead of saving it the 2nd time, use save as and replace the old file.

    this is a quick work around, simply creating a new file every time you save.
  • Joel Bruner1 Level 1 (40 points)
    I'm leaning towards an AFP problem. Here at my work, we have an XServe (10.4) but also a DAM that is running it's own AFP implementation. I am able to make corrupted PSDs on the Xserve consistently, whereas the Xinet AFP server has not had this issue. It seemed to take a few times but then I was able to simply open a file make a change and it'd get zapped. It seems that the first half or so of the file is completely filled with 00 hex. To the person who saw XML in the headers, that's usual and a good sign, the corruption I've seen is that NULLs are written for the majority of the file. From one experiment it was interesting that the size differed, with the corrupt version being 76k smaller and when data did start getting written, the offset from the "good" file was 100 bytes. Weird stuff.
  • backfliprabbit Level 1 (0 points)
    Apple needs to address this issue asap.
  • Stealth43 Level 1 (0 points)
    I believe you are right Joel. I mentioned that to Chad earlier today. If someone could, please try replicating this problem while using SMB. If it still happens then it's something to do with the rebuilt network stack as a whole... it would be nice if it were simply isolated to AFP though.

    Message was edited by: Stealth43
  • Joel Bruner1 Level 1 (40 points)
    Well I just turned on SMB and played around with my test files and wasn't able to corrupt them, so... the interesting thing is what is it doing in AFP that non-Apple AFP servers are able to correct for this? Can anyone with ExtremeZ-IP running report their results (or Dave haha
  • marc_b Level 1 (0 points)
    ExtremeZ has the same problems than the other AFP-Servers mentioned above. i am sorry to say but with the newsest ExtremeZ-IP Version 5.2.1 released this week, the same problems show up. i am currently downgrading 3 clients to 10.5.2. what a fun... marc
  • Daniel Lang Level 1 (0 points)
    It seems that it helps, when you remove the PS prefs.. But not 100% sure that it really fixes the problem. But it helped me and it worked for the first few tests. May it helps also for others...

    Cheers, Daniel
  • denbypot Level 1 (0 points)

    I am using a German version of Leopard 10.5.3 and a Synology DS107+ over wired ethernet to store my images in several subfolders. Until now I was not able to reproduce the corrupted PS3 .psd/.tiff issue. Open, reopen, changing, saving, saving as of a picture directly on the network hardisk works as normal.

    Hope that will stay this way.
  • netnothing Level 1 (55 points)
    I was able to reproduce.

    - I have a Mac Pro and a MacBook, both running 10.5.3.

    - I took a .psd file I had already created on the Mac Pro under 10.5.2. I copied that file to my MacBook.

    - I then opened the file located on the MacBook, from my Mac Pro (mounting the MacBook using AFP).

    - I made a change the the file and saved it.

    - I tried to open the file again, and it gave me the error.

  • Greg Fiumara Level 1 (0 points)
    Has anyone looked for corruption saving to an NFS share? We have had lots of problems with corrupt preference files to NFS shared home directories but never a problem with the actual files. Clients are all still running 10.5.2.
  • Mitch Cohen Level 1 (115 points)
    Has anyone tested this with Illustrator CS3? I just upgraded a client to 10.5.3 yesterday. They use Illustrator CS3 saving to a 10.4 server. So far no complaints, but I've told them to keep a look out.

Previous 1 2 3 4 5 6 Next