[TxMt] Atomic Saving / Saving Question

[Chris Thomas]

On Feb 7, 2005, at 7:12 AM, Sune Foldager wrote:

> 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.

Aliases store the file ID on HFS volumes. The change to alias 
resolution ordering was a user interface decision -- if I have an alias 
to a copy of TextMate, and I throw out the copy of TextMate, and place 
a new copy of TextMate in the location of the old TextMate, I might 
reasonably want the alias to point to the new copy of TextMate, rather 
than the old one in the Trash.

However, it appears that this discussion is academic, because HFS+'s 
implementation of exchangedata actually returns an error if one of the 
files is hardlinked.

Chris