I have an NSDocument based application. Starting in 10.5.1 users
have been been reporting that their document changes could not be
saved, and that the following has been reported to the Console:
"NSDocument called FSPathReplaceObject() and -39 was returned."
-39 is eofErr.
I've been seeing a similar problem on 10.5 with a network home
directory. The error code is different (it returns -1303,
diffVolErr), but it leads me to the conclusion that NSDocument's
default file save code isn't as robust as it could be right now. I
filed a bug report about the diffVolErr issue <rdar://5602033>, so if
you file a bug report too it would be worth mentioning that one I think.
In the case of eofErr, I'd ask your users to check their volumes using
Disk Utility. It may be possible to get unexpected EOF indications in
situations where the file's stated length and extent data don't match
up.
I cannot reproduce this myself.
I've seen in the debugger that FSPathReplaceObject is called from
[NSDocument saveDocument:]. My code does not directly call
FSPathReplaceObject.
No, it's NSDocument that uses it, to implement "safe saves". You
should be able to avoid using the default implementation by overriding
the right methods on NSDocument.
