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.
