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
