Approaching three years since Mr. Mitchell originally posted this,
I'm curious if anyone has found a workaround for this apparent
incompatibility between Microsoft Office X and caches folder
redirection?
Our school uses Microsoft Office X, Mac OS 10.5 on clients, Mac OS
Server 10.5, and some Windows stuff. Yes, our version of Microsoft
Office is old, but it's what we have for at least another six months.
I attempted to redirect the user's "Caches" folder to the local hard
drives via Workgroup Manager, but encountered this same lingering
issue.
1) A user creates a new Microsoft Word document.
2) The user successfully saves it for the first time.
3) On the second time the document is saved (excludes "Save As") it...
a) successfully saved a "Word Work File D_###" document to
Macintosh HD/private/tmp/username/Library/Caches/TemporaryItems/Word
Work File D_###"
b) deletes the original document (from wherever the user had
previously saved)
c) reports that "Word cannot complete the save due to a file
permission error. (thesis paper.doc) {OK}"
d) renames the now unsaved open document to "Word Work File L_###"
4) On the third and subsequent saves, it reports that "Word cannot
complete the save due to a file permission error. (Word Work File
L_###) {OK}"
Other than Microsoft Office X, all other applications seem to work
great, including a slew of Adobe products.
We have had a similar problem, and have solved it by re-redirecting ~/
Library/TemporaryItems. The background for this is that Apple has some
API's for "safe saving", that is first saving a document to another
file, and then replacing the original file with the new version. This
is generally a really good thing because it gets rid of the
possibility that you were in the middle of saving and something
happens (ie: someone yanks the power cable) you are left with a
partial file. With a "safe save" you are nearly guaranteed that the
file is either the new version or the old version, not some partial
version of either (or both).
However, in order to work the "safe save" system needs to be able to
delete the old file and "move" the new file into position as one
single move. This can only happen when both the temporary file and the
old version are on the same filesystem. Apple did think through this a
bit for network volumes, and so if you are writing to a network volume
it will write the temporary file to <volume mount
point>/.TemporaryItems. It gets a bit ornery if it can't write to that
volume. Please not that <volume mount point> is not the necessarily
the root of the filesystem as seen from the server, only from the
client.
For network home directories in Apple has done something a bit
different. If you are saving something to your home directory it
probably can't write to the root of the volume, so it try to make the
temporary file in ~/Library/Caches/TemporaryItems. This works great
until people like us came along and were horrified that we had all of
these cache files flying back and forth over our networks, slowing
things down. So we move the ~/Library/Caches folder to the local
volume, and go on our merry way. However, we have just created
problem: the TemporaryItems folder is no longer on the same volume as
our home folder, and so the "safe save" system breaks.
Microsoft Word is usually the application that most people complain
about, but on our setup TextEdit also failed, as did anything that
uses a bundle for its documents (iWork '08, OmniGraffle, etc). As I
said earlier, the solution is to re-redirect ~/Library/Caches/
TemporayItems back into the home folder (on the network volume). I
have placed mine back in ~/Library, and then use a soft-link, and all
of the problems have gone away.
--
Karl Kuehn
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Client-management mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
