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: Mon, 2 Sep 2002 16:15:34 +0200
Rosyna wrote:
The problem was the suggestion of foo~.txt in the current directory
(like IB and it's nibs) Whereas the data should probably be in the
Chewable Items folder (if it's still chewable in OS X) or in the
Temporary Items folder (if it's any different from the Chewable Items
folder). And it should have a guaranteed unique file name.
Mike Shields wrote:
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.
Well, I guess we are talking if not about the same thing so at least
something very near the same thing. :-)
I see two different things being dicsussed here. First, atomic saves
and secondly, how do you store a backup (or perhaps 'what is a
backup')? I think it's important to separate these issues.
An "automatic backup file" for me is a file that contains the latest
version of a specific file before that file was last saved. Can we
agree on this? I mean, if you have a program that automatically stores
a backup of your document whenever you save it, you'd expect the backup
to contain what the original file contained before you saved it the
last time, right?
To me, coming from the unix world, this file is often named something
like "foo.txt~", although we've been using the name "foo~.txt" during
the discussion so far.
Where are you Classic Mac folks expecting this kind of backups to
appear? In a hidden temporary folder? In the same folder as the
original? Somewhere else? Or doesn't classic Mac programs follow this
paradigm?
I don't have a clue because I've seldom used Mac OS < X.
Now, atomically saving files.
Many unix tools use the rename() paradigm I described earlier. Eg, if
you rsync a file from one server to another, during the transfer the
destination file is named ".foo.txt". When the transfer completes
.foo.txt is rename()'ed "foo.txt". The "copy" is atomic. Also, the "."
prefix ensures that the file is hidden if you do a normal "ls" in the
directory.
This temporary file should not be confused for the backup. It has a
different purpose, which is to ensure that saving the new content
doesn't destroy your data should your program or system suffer a crash
during the operation. The "automatic backup file" on the other hand is
an aid for the user. (an aid which is often optional).
There's also a reason for putting this temporary file in the same
directory as the original, a reason that stems from the networked
history of unix.
In a unix system you can't be sure whether a specific directory is
local or not (or at least it's difficult or error prone to find out,
but I might be wrong here). So, by keeping this temporary file in the
same directory as the original, you ensure that a rename() can be
performed even if the directory is actually mounted using for example
NFS.
So, to get back on track, it looks to me like a good solution would be
to
1) based on user preference optionally make a backup copy of the
original file;
2) make an editable copy of the original file;
3) atomically exchange the editable and original files.
The question then is, which API should you use? If at stage 2 and 3 you
use FSpExchangeFiles you'd keep aliases happy, but does this technique
work on NFS or samba volumes?
Where should the temporary file be stored? In the same directory/folder
or in a local temp folder? Who should decide? The programmer? The API?
Any thoughts?
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.