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'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.
* 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).
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).
