NSDocument called FSPathReplaceObject() and -39 was returned

  • Hello,

      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 cannot reproduce this myself.

      I've seen in the debugger that FSPathReplaceObject is called from
    [NSDocument saveDocument:].  My code does not directly call
    FSPathReplaceObject.

      The users experiencing problems have fixed their permissions and
    rebooted multiple times.  If they do a Save As..., the users never
    have this problem again with the new file, but continue to have the
    problem with the old file **in the same directory**.

      The files are never larger than a few hundred K, and are written
    upon request in my NSDocument subclass by [myNSData writeToFile:
    atomically:YES], which returns YES.

      Any ideas on why FSPathReplaceObject is returning -39 (eofErr), but
    only on some systems?  And only for a specific file?

      My software is built against the 10.3.9 SDK.

    Thank you,
      Sanford
  • On 30 Nov 2007, at 00:46, Sanford Selznick wrote:

    > Hello,
    >
    > 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.

    Kind regards,

    Alastair.

    --
    http://alastairs-place.net
previous month november 2007 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
Go to today