Re: Saving only required files in a file wrapper?

FROM : Michael Nickerson
DATE : Thu May 08 18:45:10 2008

On May 8, 2008, at 7:30 AM, Keith Blount wrote:

> Apologies for so soon a follow up, but I've just been experimenting 
> with -writeToURL:ofType:forSaveOperation:originalContentsURL:error: 
> and the results are disastrous. It turns out that *every single 
> time* it is invoked, absoluteURL is a temporary location and *not* 
> the original URL. So to use this method successfully I would need to 
> copy the whole file package across to that location every time, 
> which is exactly what I _don't_ want to do. This seems a little 
> insane to me. There must be a mechanism in place that just lets you 
> save into a package folder without having to write the whole thing 
> out every time...
>
> Thanks again and all the best,
> Keith
>


I went through some of this recently - I'm using a helper tool to 
actually save the files, and I had to figure some of this out to get 
that working right.

absoluteURL is going to always be a temp location because that's how 
the document system works - it writes to the temp location, then 
overwrites the original location if that's successful.  Keeps file 
corruption to a minimum.

absoluteOriginalContentsURL should probably be the original URL.  The 
only time it's not likely to be the original path (what's returned by 
[self fileURL]) is if the user has moved / renamed the original file 
in between when it was opened and when it's being saved.  (I'm fairly 
certain this is why you're told not to use -fileURL when writing - 
because that's not updated if the user moves / renames the file while 
it's being edited.)

If you don't want to rely on that, there's nothing stopping you from 
creating a new ivar to save the URL passed in when you read the file. 
Though that can break if the user moves / renames the file while it's 
being edited.  I know, not likely, but you can't be 100% certain on 
that.  If you'd like to do this, but want to be certain, you could get 
the original path when you read and convert it to a file alias, then 
resolve the alias when you're writing - then you're guaranteed to have 
the correct path (this is what I actually decided to do).  The only 
way that would break is if the user moves the file to a different hard 
drive, and I believe the normal NSDocument methods wouldn't work 
correctly in that case anyway (I believe the user gets shown a dialog 
saying the original file couldn't be found).

Once you have the original path (whichever way you choose to get it), 
you can do what you were before to save the files in the wrapper.  Or, 
if you want to, you can save it to the temp location, and then 
overwrite the individual files yourself using NSFileManager.  Though 
if you do that, *make sure to delete the temp file* before returning 
(if you use the same path as absoluteURL for the temp file, anyway). 
If you don't, the document system will copy it over anyway and you'll 
wind up with your original problem. I had an interesting time figuring 
that last part out.  In my case, the original files aren't actually 
writable by anyone but root, and it would "fail" when it tried to copy 
the temp files over the original files (even though my helper tool had 
actually already done that).  Made for an interesting case where the 
file was actually saved but the app didn't think so.

Hope that helps out some.


--------------------------------------
Darkshadow
(aka Michael Nickerson)
http://www.nightproductions.net