[TxMt] Atomic Saving / Saving Question

[Sune Foldager]

On 6. feb 2005, at 23:42, Ryan Schmidt wrote:

> On 01.02.2005, at 11:57, Sune Foldager wrote:
>> The disadvantage of atomic saves (for some), is that the file gets a 
>> new inode-number each time which will break hard-links and might 
>> upset aliases if they are not pointing correctly.
>
> Apple has been promoting this practice for ten years or more, and 
> aliases have always worked with it in the past.

Yes, because aliases check location first, inode second (used to be the 
other way around in OS9-). So yes, atomic saves in this fashion will 
not break aliases, but will break hard links of course. Symbolic links 
are also untouched.

> As I understand it, part of the reason for Apple providing a function 
> to do this is specifically so that aliases continue to function.

Well... Apple's function does it the same way as I described, which is 
also what their doc says. This has been a pretty standard way for a 
long time also on UNIX. Of course abstraction is always good, and who 
knows, maybe sometime the file system might support atomic saves 
directly. Incidentally that would pose a problem since now you can be 
_sure_ atomic saves break hard links, but you can't otherwise. Then a 
system function to break a hard link might be needed.

> The documentation [1] says that the "file ID" is preserved, though I 
> don't know if that's the same thing as an "inode number."

Well it can't be since inodes are not preserved by atomic saves in this 
fashion.

-- 
Sune.
:: the Cottage of Lost Play.
:: http://cyanite.org