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
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
