On 8. feb 2005, at 18:43, Chris Thomas wrote:
Huh? If I have file A hard linked with B and I "atomically" replace A (i.e. write A.new, move A.new to A) then I will break the link between A and B. That's the issue here, and that's certainly what happens in the scenario I just described :-). No HFS+ errors here.
Right, but I'm talking specifically about the exchangedata system call (or FSExchangeObjects). exchangedata is a Darwin VFS operation. It calls into the file system implementation to perform the atomic exchange. For HFS+, it explicitly preserves the file ID. I had assumed it would preserve hardlinks as well, but it turns out that it just errors out if one of the files is hardlinked (or has ever been hardlinked).
I see... interesting. Of course somewhat unfortunate that it fails with multilinked files.... then, preserving the id/inode will only help with alises (if the file was moved since the alias was created).