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