Re: Storing NSDocument data in packages/bundles
Re: Storing NSDocument data in packages/bundles
- Subject: Re: Storing NSDocument data in packages/bundles
- From: Quincey Morris <email@hidden>
- Date: Wed, 31 Dec 2008 04:46:16 -0800
On Dec 31, 2008, at 01:32, Kyle Sluder wrote:
For safe save operations, AppKit writes the data to a temporary file
on the same volume, and then swaps the old file with the new, which is
an atomic operation. If it can't do that, it will rename the original
file and write the new one with the old name. This is why absoluteURL
or absoluteOriginalContentsURL won't necessarily jive with -fileURL
(see the comment header for -[NSDocument
writeSafelyToURL:ofType:forSaveOperation:error:] for more details).
The upshot is that absoluteOriginalContentsURL will be a URL which you
can use to access your existing on-disk data, whether or not AppKit
has temporarily renamed it.
I don't see how trying to do this in -
writeToURL:ofType:forSaveOperation:originalContentsURL:error: is ever
going to work.
If you are given (basically) an old and new package location, then
you're forced to copy everything:
-- Trying to write changed files in the old location would be a really
bad idea.
-- Moving the unchanged files from the old location to the new
location would probably work (if the save operation is a pure save,
not a save-as or save-to), but would be a really bad idea if there was
an error during the save (because the contents of the new location
would presumably get thrown away).
The *real* question here is: what's a *safe* strategy for saving a
package by changing parts of it? You really need a single atomic
operation to commit the changes, and most file systems don't provide
this for an arbitrary set of files. NSDocument's answer is that there
isn't a safe strategy, so it always saves by creating a copy. (And
even that's not perfectly safe if the file system doesn't provide the
equivalent of FSSwapFiles.)
Using Core Data as the storage mechanism for blobs of data is a
possibility, but it's also a PITA because:
-- you likely need to turn off NSPersistentDocument's undo handling
and provide your own
-- Core Data doesn't have save-to, and its save-as sucks (does a store
migration)
-- if you have a lot of data, Core Data is going to keep copies of
much of it in internal caches
My suggestion would be to go ahead and use a package document format,
and to copy the unchanged files, and see how long it takes. If the
save times are unacceptable, then a database solution (not Core Data)
is probably the next step.
FWIW
_______________________________________________
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