[TxMt] Atomic Saving / Saving Question
chris at m-audio.com
Mon Feb 7 17:29:45 UTC 2005
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.
More information about the textmate