Re: Tracking files the right way
Re: Tracking files the right way
- Subject: Re: Tracking files the right way
- From: Mike Shields <email@hidden>
- Date: Fri, 30 Aug 2002 13:15:01 -0600
See the way Apple has requested things be done in the past is to start
saving the new content into <Temporary Items Folder>:Foo.whatever. The
temp items folder is typically in someplace local that the user has
write access to. In OS 9 this was a hidden folder[1]. On OS X this is
usually somewhere on the boot volume, very likely /tmp. Once the save
was complete, then call FSpExchangeFiles and the switch would occur.
And finally delete the (now) old content in <Temporary Items Folder>.
Doing this preserved the file ID of the edited file on HFS+ (and any
other filesystem that has unique identifiers for files). Doing what you
suggested preserves the path, but nothing else.
For files which are too large to read in all at once into memory, or
you want to mmap, you can still make a copy first, edit that, then
FSpExchangeFiles the two files. It's still follows the same general
path as the other case.
Apple DTS released a package called MoreFiles which had an improved
FSpExchangeFiles wrapper that handled cases where FSpExchangeFiles
wasn't implemented (DOS formatted volumes mostly then). This code still
works today. The benefit of using <Temporary Items Folder> is that this
is guaranteed to be cleaned up at some point AND it doesn't clutter up
your folders with foo~.whatever files (I always hated having to
manually clean those up). Also using MoreFiles, I believe that it
handed the case of the destination being full/not enough room anywhere
to save the temp copy. No need for every developer to go and reinvent
the wheel. There's code out there to do all this in the proper manner.
In this case, I think we're arguing the same point. Rosyna and I are
arguing that following what Apple's suggested and using
FSpExchangeFiles is the same thing but more compatible with non-path
based solutions.
Mike
On Friday, August 30, 2002, at 07:03 AM, Malte Tancred wrote:
On fredag, aug 30, 2002, at 14:17 Europe/Stockholm, Rosyna wrote:
You'd create the new data in the temporary items folder, like Inside
Macintosh says, then you'd save the data to the new file and call
FSpExchangeFiles. There is no need to second guess it's functionality
except that it will not work on UFS volumes. (And is probably one of
the reasons so many apps don't work on UFS)
I don't follow you. I don't think I'm talking about second guessing
enything.
The only thing I wrote was that if you want your save operation to be
atomic and you try to accomplish this by following the method
suggested by Chris Hanson, in case of a crash before the call to
FSExchangeObject is made, the original data will be found in foo.txt
and the _new_ data will be found in foo~.txt. Are you with me?
I just thought that this might be a bit confusing and kind of
backwards. Perhaps I'm wrong.
I wrote:
This solution relies on the file names communicating what have been
done. The former example - using FSExchangeObjects - could perhaps
look at the dates of the files to see that foo~.txt is actually
newer than foo.txt, and by that deduce that the app crashed before
the save was completed.
Perhaps I should clarify what I meant.
Suppose we use Chris' example usage of FSExchangeObject, this is what
happens if everything goes well:
1 User hits cmd-s to save the document
2 The application begins the atomic save operation
2.1 ...by storing the new data in foo~.txt
2.2 ...by exchanging foo~.txt and foo.txt
If the application or OS crash just after or during 2.1 but before 2.2
(the atomic FSExchangeObject function call) the new content will/could
be in foo~.txt and the original content will still be in foo.txt.
Now, when the user restarts the application and opens foo.txt again,
the application could ask the user if she wants to have a look at the
_new_ data saved to foo~.txt.
To be able to do this - to determine if foo~.txt contains a backup of
foo.txt or new data that never got committed to foo.txt - the
application would have to compare the dates of foo.txt and foo~.txt (I
think).
If we instead use my suggestion (which might not be that serious, i
dunno, it was just a thought) the application would simply have to
look for the presence of foo.txt-new.
If it's there it means the app or OS crashed on us in the middle of a
save and we can ask the user if she wants to have a look at the edited
data; if its not there just open foo.txt.
I don't know if this makes any sence to you. I don't even know if it
makes any sence at all. As I wrote before, t'was just a thought.
Cheerio,
Malte
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.