GNU bug report logs - #6960
mv refuses to move a symlink over a hard link to the same file

Previous Next

Full log

Message #65 received at 6960 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jim Meyering <jim <at> meyering.net>
Cc: 6960 <at> debbugs.gnu.org, Anders Kaseorg <andersk <at> MIT.EDU>
Subject: Re: bug#6960: mv refuses to move a symlink over a hard link to the
	same file
Date: Wed, 04 Jan 2012 14:52:28 -0800

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.