56643 Views Previous 1 2 3 4 5 … Next 190 Replies Latest reply: Jul 9, 2008 2:23 PM by trouspinette Go to original post
Alright guys, I'm getting the feeling that we figure out Bridge and stop working directly off the server. I know my admin has always said keep things local.
Little feedback on the Adobe forums: http://www.adobeforums.com/webx/.59b56503/8
I'm weighing my options to downgrade to 10.5.2 for now. It bites to lose work and have to redo it. But we all know we'll do a better job the second time around. Right?
I would encourage anyone working off an Xserve to look into Version Cue. Although the initial setup takes some mental adjustment, the workflow is pretty great, and avoids precisely this issue.
When you "check out" a file from the Version Cue Server (using Bridge or the Adobe Dialog) the file is copied to your local machine (to ~/Documents/Version Cue/ProjectName by default). All subsequent saves are local, overwriting that file, until you "check in" and the file is copied back to the Server as a new "version". All "versions" remain available on the server until explicitly deleted.
Since the actual saves are local, and the "check in" network traffic is simple copying, the current 10.5.3 issue is avoided completely.
One gotcha, be careful if you're running Network Homes (which some Xserve users might be). Then the user homes (and hence, the Documents folder) are actually network shares! You can explicitly set an alternative "Local Project Files" path for Version Cue, but it's a per project setting and must be remembered when you first connect to a new project (though for many users, a single general-purpose Version Cue project might be sufficient).
One of my users updated to 10.5.3 this morning and reported the file not recognized error for a TIFF saved using Photoshop CS2 version to our server. We work off the server and are running Xinet FullPress (file and print server) and WebNative Venture (DAM solution). This is the first problem like this we have had since switching to a fully server-based workflow a little over a year ago.
With no time to even begin searching the forums for an answer, we decided to do an archive and install and put the machine back on 10.5.2. Problem went away. We only have a handfull of Leopard machines, so they were told do not update to 10.5.3 for the time being. The one affected user's machine was down for about 2 hours total.
Our Intel xserve is running Tiger Server. We do not use Apple's AFP services, since we use Xinet for AFP. So even third party AFP server was affected by a client updating to 10.5.3. The majority of our users still run Tiger. Nothing against Leopard, but in a high production environment stability is more important than anything else when you have a lot of third party software that has to play nice together. That said, we have had remarkably few problems directly attributable to using Leopard client in our workflow. Until today.
Having the same problems as the original post. Saving to server results in hopelessly corrupt files. CS2 and CS3 are affected for sure. Saving locally and copying seems to be the band-aid for now. I've seen various posts that indicate that it really doesn't matter what type of fileserver you are running, it's the fact that you are saving to a network volume.
The corrupt files are easy to spot in bridge, they have a very pixelated preview.
Here exactly the same thing in OSX 10.5.3, working on a Xserve 10.5.3. The 10.5.2 machines which also works on the same Xserve doesn't have this problem. I think it has something to do with Appletalk. Disabled Appletalk on the server and on the workstation. After a reboot of both macines I haven't got the problem so far...
So Adobe "never officially" supported saving through a network, because they have a "better" solution. Maybe so, but here we are in the real world, and many of us don't have a need or desire "to create a TPS report" every time we want to save a file to the server. Until a certain software company with a de-facto monopoly on hi-end imaging gets a certain part of its anatomy out of another part, I suggest using a macro program like Quickeys to change the command-s to a command-shift-s, or use the built in ability to change the "save" keyboard shortcut to something you would never accidentally hit. Losing a file this way is unacceptible.
This is an outrage.
If most of you are like me, and don't have time to downgrade or implement Version Cue, I may have a simple work around to avoid an accidental corruption. If a "Save As" avoids corruption, disable the Command-S for "Save" in the Keyboard Shortcuts and apply it to "Save As". If you any of you find out "Save As" isn't an absolute corruption saver, please post here ASAP. Thanks.
we were so happy about this latest update because finally our machines sleep function worked and spaces worked better with adobe Creative suite... But later on the day we found out that not everything was right.
Photoshop had corrupted files on the server and kept crashing indesign links.... now we have downgraded and lost some files which sadly aren't on the latest backup tapes!
Ben R wrote:
[quote]Officially, Adobe have never supported saving over a network. The only supported approaches are: 1. Copy locally, open and edit, save locally and copy back or 2. Use Version Cue (which basically does this for you behind the scenes). [/quote]
My point exactly, which I stated in my earlier post.
The fact that the header is corrupted in the files being worked on across the network
has to do with data not being properly written back and finalized on the server.
Possibly 10.5.3, possibly more something in 10.5.3's network infrastructure
( don't know if these are being done wired through ehternet or wirelessly),
but the fact the files are saving correctly fine locally, and then can be copied over
to the network and work fine, points to write/reads problems across the network to the
.psd and .tiff files while in use.
I know that many of you don't work this way, but since if you call Adobe they'll wag the finger
at you for working this way, and so will Apple, it might be time to change your way of operation.
We had to in our environment, and once we got over the initial "why why wah-wah"
eventually we forgot we even used to do it the "wrong" way.
Message was edited by: Terry Jackson1
Hey there all. I too am having the same issue working on the Xserve using Photoshop CS3 after the 10.5.3 upgrade. I have tried as a test on 6 images, creating .psd file through the network and they have all prompted the same message "could not complete your request ...". I have tried the following:
- maually changing the extensions to .tif, .eps, etc.
- using older versions of photoshop
- using another computer running older version of OS
- copying to my desktop, and re-opening the .psd
- trying to place file in Illustrator, to export back out
- double clicking & going through the open option.
- saving the files as "save as", or save
- saving the file as a layered .tif
In all cases they all corrupted working off the server.
The only solution is where the problem did not appear was copying the file to the local disk and working locally. The other solution might be to reload the previous operating system. Not sure if that's possible.