This discussion is archived
56165 Views 190 Replies Latest reply: Jul 9, 2008 2:23 PM by trouspinette
Currently Being ModeratedMay 30, 2008 9:00 AM (in response to chadclark)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.Mac OS X (10.5.2)
Currently Being ModeratedMay 30, 2008 9:11 AM (in response to chadclark)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.MacBook, Mac OS X (10.5.2)
Currently Being ModeratedMay 30, 2008 9:32 AM (in response to Terry Jackson1)
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).
Currently Being ModeratedMay 30, 2008 9:37 AM (in response to Ben R)
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.
Currently Being ModeratedMay 30, 2008 10:11 AM (in response to Bill Raab)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.G5, Mac OS X (10.5.3)
Currently Being ModeratedMay 30, 2008 10:19 AM (in response to chadclark)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.MacBook Pro, Mac OS X (10.5.3)
Currently Being ModeratedMay 30, 2008 10:51 AM (in response to Joel Bruner1)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: Stealth43G4, MBP, G5, Mac OS X (10.5.3)
Currently Being ModeratedMay 30, 2008 11:17 AM (in response to Stealth43)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 hahaMacBook Pro, Mac OS X (10.5.3)
Currently Being ModeratedMay 30, 2008 11:27 AM (in response to Joel Bruner1)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... marc10 different machines in the netwok, Mac OS X (10.4.11)
Currently Being ModeratedMay 30, 2008 11:33 AM (in response to chadclark)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, DanielMacPro, Mac OS X (10.5)
Currently Being ModeratedMay 30, 2008 11:40 AM (in response to chadclark)Hi,
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.MacPro, Mac OS X (10.5.3)
Currently Being ModeratedMay 30, 2008 12:43 PM (in response to chadclark)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.
-KevinMac Pro 2.66, MacBook 2.4, Mac OS X (10.5.3)
Currently Being ModeratedMay 30, 2008 1:19 PM (in response to Joel Bruner1)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.MacBook Pro 15", Mac OS X (10.5.3)
Currently Being ModeratedMay 30, 2008 1:47 PM (in response to chadclark)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.