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

[Jim Meyering]

Matt McCutchen wrote:

> If mv is asked to move a symlink over a hard link to the same file, it
> fails with the message, "A and B are the same file".  There is no reason
> why it should complain rather than perform the move.

Actually, there is a very good reason.  See below.

> Example:
...
> $ touch New_York
> $ ln New_York localtime
> $ ln -s New_York localtime.new
> $ ls -l
> total 0
> -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
> $ ~/coreutils/coreutils.usr/bin/mv localtime.new localtime
> /home/matt/coreutils/coreutils.usr/bin/mv: `localtime.new' and `localtime' 
> are the same file

Here, your regular file, New_York, happens to be empty.
That is a special, degenerate case.
If you lose this file, via use of mv, you lose nothing at all.
Well, in general, you might lose convenient access to the destination inode,
if it had two or more links.
But what if it contained a copy of some important document?


It is a problem of perception.
The user sees two files, A and B.
The naive user sees that they have the same contents,
but does not notice they are symlinked.  May not even
know what a symlink is...
Our user decides to get rid of the duplicate.

The lucky naive user moves the real file onto the symlink (say "mv A B")
and that succeeds.  If however, s/he uses the other argument ordering
("mv B A") and moves the symlink onto the real file, some versions
of "mv" would leave our poor user with no copy of the original file.
This is called "data loss" ;-)  The user did nothing wrong, yet ended
up destroying what may have been important data.  That is why GNU mv
deliberately refuses to perform the offending operation.

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.

This is not a bug in GNU mv.
It is a deliberate feature.

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