Re: NSDocument package saving invalidates wrapper? Options?
Re: NSDocument package saving invalidates wrapper? Options?
- Subject: Re: NSDocument package saving invalidates wrapper? Options?
- From: Mike Abdullah <email@hidden>
- Date: Sat, 01 Sep 2012 21:23:31 +0100
On 23 Aug 2012, at 14:12, Markus Spoettl <email@hidden> wrote:
> I have an NSDocument based app that has uses packages do to store a complex structure.
>
> When I open a document, I keep the wrapper around handed to the document in
>
> -readFromFileWrapper:ofType:error:
>
> in order to lazy-load parts of the package when my app needs them. Similarly, I keep the wrapper when saving (which is the same object unless it's a new document that didn't have a wrapper before). And here the trouble starts.
>
> When I try to lazy-load package files after saving by requesting -regularFileContents on the corresponding wrapper that are located somewhere down the wrapper hierarchy, they are still available (meaning the sub-wrapper objects are there) but the content returned is nil.
>
> The documentation states that this can happen when the user moves the file after the wrapper has been created. I suspect that this is a side effect of safe-saving, which writes temporary files and moves them into place when everything worked out correctly.
>
> I'm fixing this by calling -readFromURL:options:error: on the document package's root wrapper in the completionHandler of NSDocument's
>
> -saveToURL:forSaveOperation:completionHandler:
>
> before calling the original completionHandler (I'm pasting the relevant code below).
>
> As it's not mentioned in the documentation anywhere (meaning saving packages will invalidate wrappers), it doesn't feel quite right. I've been using this a couple of months now without adverse effects, though.
>
> I'm wondering this is expected behavior and/or if there's a better way to make sure the wrapper points to the right place once saving is complete.
>
> I'm using the 10.7 SDK.
>
> Regards
> Markus
>
> - (void)saveToURL:(NSURL *)url ofType:(NSString *)typeName
> forSaveOperation:(NSSaveOperationType)saveOperation
> completionHandler:(void (^)(NSError *))completionHandler
> {
> [super saveToURL:url ofType:typeName
> forSaveOperation:saveOperation
> completionHandler:^(NSError *error) {
>
> if (error == nil) {
> [rootFileWrapper readFromURL:url options:0 error:&error];
> }
>
> completionHandler(error);
> }];
> }
Hi Markus,
It seems you're right; this is a side-effect of how NSDocument does safe-saving. If the file wrappers internally hold onto the URL they were last written to, that's no good if the file moves out underneath them. To cope they'd have to be using a bookmark or file reference URL instead. Apple might well be doing so in 10.8 or a later OS, but if you need to target 10.7, that doesn't help!
I'd make two changes to your routine:
* Instead override -writeSafelyToURL:…. This is the method that's actually responsible for doing the special file-handling
* You probably only want to ask the file wrapper to re-read if the operation is a regular Save, Save As, or Autosave-in-place. For others, you want to remain pointing at the original URLs I believe
One other question though, what does your writing code look like? Are you overriding one of the -write… methods? Or implementing -fileWrapperOfType:… ?
_______________________________________________
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