Re: Storing NSDocument data in packages/bundles
Re: Storing NSDocument data in packages/bundles
- Subject: Re: Storing NSDocument data in packages/bundles
- From: Markus Spoettl <email@hidden>
- Date: Wed, 31 Dec 2008 12:11:11 -0800
On Dec 31, 2008, at 11:29 AM, Quincey Morris wrote:
It's rather surprising that NSDocument's save-as-copy-and-move
strategy that works so well for single files backfires so heavily
in my case.
Well, to be accurate, it's not a NSDocument issue, it's a problem
with updating in place more than single file vs file package.
Incidentally, there's a fairly simple safe strategy for file packages:
-- Use a single "index" file that lists all the files that make up
the current version of the document.
-- When saving, first write all the changed data to new files with
new names.
-- Then update the index file atomically.
-- Then delete all the out of date files.
But that has a few drawbacks:
-- The individual file names are potentially different every time
you save (which may or may not matter to you).
-- You need periodic housekeeping to detect orphaned files (due to
saves that failed for some reason) and delete them.
-- Differences in file name encodings/naming rules might cause
problems if the whole package is manually copied from one file
system to another.
Sounds like it should be doable quite easily in my case. Thanks very
much for the verbosity.
If you can come up with any acceptable safe strategy, then it's
still an issue how to integrate it into NSDocument.
writeSafelyToURL: seems like the obvious place, but its
documentation says "must call super" if overridden, and calling
super is probably going to mess up your strategy.
That's what I thought too. What's the point of implementing a
different way to safely save things when at the end you have to use
the built-in behavior. It really doesn't make any sense, I believe
this must be a documentation inaccuracy which really meant to say "be
sure to call super unless you're doing you completely home-grown
saving stuff on your own". Pure speculation of course.
BTW, before you decide that long save times are unacceptable, take a
look at how Amadeus behaves when saving large sound files. It has
the best "slow" save (from a usability point of view) of any app
I've seen.
Which brings me to something else. How does one do that, meaning how
can I provide a save progress. I can't use a second thread to save the
document because (I think) AppKit expects that -writeSafelyToURL:
returns when it's done. Starting a thread and off-loading the work
there so that I can update the UI while the operation is going on
isn't going to work. An asynchronous mechanism where I can tell the
document what is has been saved similar to NSApplications -
applicationShouldTerminate: and -replyToApplicationShouldTerminate:
would be what I'd need for that. Currently the only way of doing a
save progress with user interaction is rolling my own save operation
altogether, which has lots of implications (for example the behavior
when saving in the process of app termination). Am I overlooking
something obvious here?
Regards
Markus
--
__________________________________________
Markus Spoettl
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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