On Dec 31, 2008, at 10:12, Markus Spoettl 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.
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.
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.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
