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

[Paul Eggert]

On 01/04/12 14:30, Jim Meyering wrote:
> You could form the symlink-free full name of the referent, abs_src
> and then test same_name (abs_src, dst_name).

That doesn't sound right, since the symlink may resolve differently
after it's moved.  For example:

$ ls -ldt lt ny d d/lt.new
drwxr-xr-x. 2 eggert eggert 4096 Jan  4 14:44 d
lrwxrwxrwx. 1 eggert eggert    2 Jan  4 14:26 d/lt.new -> ny
-rw-r--r--. 2 eggert eggert    2 Jan  4 14:26 lt
-rw-r--r--. 2 eggert eggert    2 Jan  4 14:26 ny
$ mv d/lt.new ny
$ ls -ltd lt ny
lrwxrwxrwx. 1 eggert eggert 2 Jan  4 14:26 ny -> ny
-rw-r--r--. 1 eggert eggert 2 Jan  4 14:26 lt

This scenario is almost equivalent to the problematic one in
the original bug report, the one where 'mv' refuses to move,
and yet here 'mv' charges right ahead.

I'm becoming more inclined to think that Anders's argument:

> mv is already perfectly happy to atomically overwrite a 
> regular file with a symlink (even if that causes data loss)

is a valid one.  Currently 'mv' is pretty complicated in this
area, so complicated that I can't easily suggest a fix, but
I'm starting to think that mv shouldn't reject either
"mv localtime.new localtime" or "mv localtime.new New_York"
in Anders's scenario.  That is, it should simply compare inode
numbers without dereferencing them.