On 2 Sep 2012, at 08:04, Markus Spoettl <ms_li...@shiftoption.com> 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 (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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
