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: Sun, 02 Sep 2012 11:05:01 +0100
On 2 Sep 2012, at 08:04, Markus Spoettl <email@hidden> wrote:
> On 9/1/12 10:23 PM, Mike Abdullah wrote:
>> 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!
>
> Thanks for the reply! Not sure I understand, are you saying in 10.8 this problem is non-existent? I don't see anything in the AppKit release notes indicating a change of behavior.
I was saying might have made the problem non-existent. I have absolutely no idea if they have or not. But that if you're targeting 10.7 anyway, it's still something you have to worry about.
>
>> 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
>
> Not sure what advantage that would give me generally speaking, but I'm using background saving (by returning YES in -canAsynchronouslyWriteToURL:::). It appears that -writeSafelyToURL: is being called on the background thread, while the completion handler in -saveToURL:… is called on the main thread. I'll have to think about the implications of that.
Well the main advantage is that you're keeping related code together. -writeSafely… is responsible for doing the file swapping + temporary location logic, so you might as well have your code for that alongside it.
Also, it's *possible* but unlikely for the doc system, or you being careless, to call one of the older -save… methods instead of the new one.
>
>> * 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
>
> OK, that sounds like a good idea, although my app doesn't support any save operations other than Save and Save As (no versions, no autosaving).
Any particular reason? It seems a shame not to adopt modern standards. You're losing out on a nice degree of crash protection for a start.
>
>> One other question though, what does your writing code look like? Are you
>> overriding one of the -write… methods? Or implementing -fileWrapperOfType:…
>> ?
>
> Yes, I'm using -fileWrapperOfType::
>
> - (NSFileWrapper *)fileWrapperOfType:(NSString *)typeName error:(NSError **)outError
> {
> NSFileWrapper *dataWrapper = [appData documentFileWrapper];
> [self unblockUserInteraction];
>
> return dataWrapper;
> }
>
> -documentFileWrapper basically prepares the wrappers (updates, replaces or removes sub-wrappers as necessary).
Aha, so I'd say you have another alternative in which case:
You could implement -writeSafely… so that it calls straight through to -writeToURL:…
Implement -writeToURL:… so that it calls -fileWrapperOfType:… and then writes that out to the URL *atomically*
i.e. you'd be taking over responsibility for atomic saves by making NSFileWrapper do it. That way the wrapper should neatly track where the files really end up.
_______________________________________________
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