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.