Re: Tracking files the right way
Re: Tracking files the right way
- Subject: Re: Tracking files the right way
- From: Malte Tancred <email@hidden>
- Date: Fri, 30 Aug 2002 15:03:59 +0200
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.