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

[Jim Meyering]

tags 6950 + notabug
close 6950
thanks

Jim Meyering wrote:
> 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.

There was no further discussion, so I've closed this.