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

[Anders Kaseorg]

This refusal makes it impossible to overwrite a hard link with a symlink 
_atomically_.

See for example http://bugs.debian.org/654596 .

In reply to message #17:
> One may argue that there is no data loss when the destination link count 
> is 2 or more, but once the destination has been unlinked, it may be very 
> challenging to locate another copy.

I would instead argue that there is no data loss when replacing a hard 
link foo with a symlink to bar, as long as foo and bar are _different_ 
hard links to the same inode.  In that case, locating the other copy is 
not a problem because the symlink will still be valid.

For example, in the example from the original report:
  -rw------- 2 matt matt 0 2010-08-31 17:10 New_York
  -rw------- 2 matt matt 0 2010-08-31 17:10 localtime
  lrwxrwxrwx 1 matt matt 8 2010-08-31 17:11 localtime.new -> New_York
mv may reasonably refuse to overwrite New_York with localtime.new, but it 
should not refuse to overwrite localtime with localtime.new.

> Personally, I prefer the semantics of 'mv -f --backup=numbered' so use a 
> shell alias.

mv --backup=numbered is not atomic; it expands to two rename() syscalls, 
between which the target doesn’t exist at all.

Anders