bug#6960: mv refuses to move a symlink over a hard link to the same file

[Anders Kaseorg]

On Wed, 4 Jan 2012, Eric Blake wrote:
> But whether the inability to atomically overwrite a directory with a 
> symlink should carry over to a refusal to atomically overwrite a regular 
> file with a symlink is a different matter.

To be clear, mv is already perfectly happy to atomically overwrite a 
regular file with a symlink (even if that causes data loss), as long as it 
doesn’t detect that the symlink points to the same inode.

The only purpose given for this same-inode check is preventing a 
particular kind of accident, and I claim that this purpose would be better 
served by a same-path check, because the same-inode-but-different-path 
case is useful and can’t allow that kind of accident (and indeed, won’t 
lose data at all).

> Maybe we should fix that, to make mv --backup use link()/rename() rather
> than rename()/rename(), so that there is no window where the target
> doesn't exist.

Perhaps, but that’s not a good solution to _this_ problem, because a 
script that wants to do this kind of atomic replacement would then need to 
go delete the backups (potentially resulting in more data loss).

Anders