Re: Saving only required files in a file wrapper?
Re: Saving only required files in a file wrapper?
- Subject: Re: Saving only required files in a file wrapper?
- From: Keith Blount <email@hidden>
- Date: Thu, 8 May 2008 02:08:57 -0700 (PDT)
Many thanks again for your replies; much appreciated.
On the surface, it look as though Graham's suggested -writeToURL:ofType:forSaveOperation:originalContentsURL:error: would be the ideal solution, allowing me to write just individual files for an NSSaveOperation or copy the whole project for an NSSaveAsOperation.
The trouble is that the documentation is really unclear on this. It seems to say that you should use this method for exactly what I want but then it says that you can't rely on the URLs passed in!
Firstly, the docs say the following about this method:
"You can override this method instead of one of the three simple writing methods... if your document writing machinery needs access to the on-disk representation of the document revision that is about to be overwritten."
Which is exactly what I want - I want access to the on-disk package where I know all of the contents are safe so that I can only save a handful of changed files within the package, without having to overwrite the entire package (which could take a long time for large packages).
However, it then goes on to say:
"The value of absoluteURL is often not the same as [self fileURL]. Other times it is not the same as the URL for the final save destination. Likewise, absoluteOriginalContentsURL is often not the same value as [self fileURL]."
Huh? It adds that "If absoluteOriginalContentsURL is nil, either the document has never been saved or the user deleted the document file since it was opened." That bit makes sense. It is the above sentence that is worrying. I can see why absoluteURL wouldn't be the same as [self fileURL] if the save operation was NSSaveAsOperation (though the docs don't go into this). But outside of the document never having been saved or it having been deleted so that absoluteOriginalContentsURL is nil, why wouldn't absoluteOriginalContentsURL be the same as [self fileURL]?
On the other hand, if absoluteOriginalContentsURL represents a copy the OS has made of the package, then everything should be there and I should still be able to write to it and have the OS write everything back safely. Right? I hope. That is, I would expect this method - given that it says that you can use this method "if your document writing machinery needs access to the on-disk representation of the document revision that is about to be overwritten" - to at least provide a copy of the entire package at absoluteOriginalContentsURL even if that is not the original -fileURL. (To be really safe I could always check inside absoluteOriginalContentsURL to ensure that a file I know should be in every package is there...)
My experience certainly suggests that -fileURL will generally be the same as the passed-in URL. In my -readFromURL:... method, I have just realised that I'm calling -fileURL instead of absoluteURL, which I absolutely shouldn't be doing. But in two years not one of the thousands of users of my app has complained that their project wouldn't open. In the case of my app, though, the package is guaranteed to be on disk before -readFromURL: is ever called (you can't create a blank project without it already having a package on disk), so it seems that -absoluteURL in -readFromURL: only differs from [self fileURL] if the document is a blank, unsaved one. (Obviously I can't rely on this behaviour and will be changing it to use -absoluteURL forthwith.)
Sorry for the long, rambling reply. I'm just trying to get my head around the best way of doing this, and the (usually excellent) docs seem a little obtuse in this area.
Many thanks again,
Keith
----- Original Message ----
From: Ken Thomases <email@hidden>
To: Graham Cox <email@hidden>
Cc: Keith Blount <email@hidden>; Cocoa-Dev List <email@hidden>
Sent: Thursday, May 8, 2008 3:36:05 AM
Subject: Re: Saving only required files in a file wrapper?
On May 7, 2008, at 9:06 PM, Graham Cox wrote:
> On 8 May 2008, at 10:26 am, Keith Blount wrote:
>
>> The trouble with all of these methods is that they tell you not to
>> rely on fileURL
>
> My interpretation of that advice is that at the time the read... and
> write... methods are called, the document hasn't set up -fileURL, so
> in that sense you can't rely on it (i.e. don't call -fileURL from
> within these methods). But the URL passed to the methods themselves
> as a parameter is definitely reliable. So provided you use the
> parameter you'll be fine.
I think it means more than that. NSDocument tries to be smart about
atomic writes and backups. The URL passed into the write... methods
is not expected to be the same as the document's current location on
disk. You are to write the document, in whole, to the temporary
location provided to you (about which no assumptions should be made),
and then NSDocument will take care of swapping the newly-written
document with the old document and deleting the old document.
Obviously, this runs directly counter to Keith's desires.
Unfortunately, I don't know how to override these smarts in
NSDocument, other than perhaps what I described earlier with
NSFileWrapper.
-Ken
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden