Saving an NSDocument safely

  • Hello,

    I have an NSDocument, and in order to save it, I override the method:
    -saveToURL:ofType:forSaveOperation:delegate:didSaveSelector:contextInfo:

    In order not to lose the original file until I am sure saving was
    completed properly, I save in a temporary file, and when this is done,
    I delete the original file, and rename my temporary file.

    While this work fine in 10.4, with 10.5, the next time I try saving
    the file, I get the message 'The location of the document "mydoc"
    cannot be determined'.

    It seems that the NSDocument is confused by the fact that the file has
    diasppeared, even though a new one has taken its place.

    Is there a way to tell the NSDocument that the new file is really the
    one that was saved? Otherwise, is there another way to make sure the
    file was saved properly before losing the original one?

    Thanks,
    Thomas
  • On 11 Jan 2008, at 10:47, Thomas Thiriez wrote:

    > I have an NSDocument, and in order to save it, I override the method:
    > -
    > saveToURL:ofType:forSaveOperation:delegate:didSaveSelector:contextInfo
    > :
    >
    > In order not to lose the original file until I am sure saving was
    > completed properly, I save in a temporary file, and when this is done,
    > I delete the original file, and rename my temporary file.

    Aren't you re-inventing the wheel here?  Doesn't the framework already
    do this?

    Kind regards,

    Alastair.

    --
    http://alastairs-place.net
  • On Jan 11, 2008, at 6:57 AM, Alastair Houghton wrote:

    > On 11 Jan 2008, at 10:47, Thomas Thiriez wrote:
    >
    >> I have an NSDocument, and in order to save it, I override the method:
    >> -
    >> saveToURL:ofType:forSaveOperation:delegate:didSaveSelector:contextInfo
    >> :
    >>
    >> In order not to lose the original file until I am sure saving was
    >> completed properly, I save in a temporary file, and when this is
    >> done,
    >> I delete the original file, and rename my temporary file.
    >
    > Aren't you re-inventing the wheel here?  Doesn't the framework
    > already do this?

    Yes, the framework does this in -[NSDocument writeSafelyToURL:..].
    Using FSExchangeObjects doesn't result in the problem the OP mentions,
    but the temp file and destination file have to reside on the same
    volume.  I had to write my own implementation of writeSafelyToURL:
    yesterday since 10.5's safe saving is broken.

    --
    adam
  • On Friday, January 11, 2008, at 02:06PM, "Kyle Sluder" <kyle.sluder...> wrote:
    > On Jan 11, 2008 11:24 AM, Adam R. Maxwell <amaxwell...>  wrote:
    >> Yes, the framework does this in -[NSDocument writeSafelyToURL:..].
    >> Using FSExchangeObjects doesn't result in the problem the OP mentions,
    >> but the temp file and destination file have to reside on the same
    >> volume.  I had to write my own implementation of writeSafelyToURL:
    >> yesterday since 10.5's safe saving is broken.
    >
    > Please do elaborate.  This is important to one of my projects, and I
    > haven't experienced any issues with safe saving on 10.5.

    http://www.cocoabuilder.com/search/archive/cocoa?words=FSPathReplaceObject

    In our case, this appears related to extended attributes on AFP volumes.  I came up with a workaround that's now used as a fallback if we're on Leopard and NSDocument fails to save the file, but I'm not very enthusiastic about this.  E-mail offlist and I'll send a link to the code (BSD license).

    --
    adam
previous month january 2008 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 31      
Go to today