Re: mv silently does nothing for hard links

[Paul Eggert]

Jim Meyering <address@hidden> writes:

> However, I read "does not remove the file" as saying one should not
> be able to use rename to destroy OLD as well as NEW.

I worry that if we try to make "mv" smart, and work around "rename"'s
glitches, we'll end up digging a deeper hole than if we just live
with the glitches (which at least are standardized).

Here is the sort of thing that I'm worried about: it is a problem that
I just found with coreutils 5.0 on Solaris 7.  It shows where GNU mv
(in a sense) destroys both the source and the destination.

   $ mkdir d; ln -s d l; ln l l/l; ls -ld l d l/l
   ln: `l': warning: making a hard link to a symbolic link is not portable
   drwxr-sr-x   2 eggert   faculty      512 Apr  9 13:40 d
   lrwxrwxrwx   2 eggert   faculty        1 Apr  9 13:40 l -> d
   lrwxrwxrwx   2 eggert   faculty        1 Apr  9 13:40 l/l -> d
   $ mv ./l/l .  
   mv: cannot move `./l/l' to `./l': No such file or directory
   $ ls -ld ./l/l ./l
   ./l/l: No such file or directory
   ./l: No such file or directory

POSIX mv will simply do nothing silently here, because that's what
rename does.  Neither behavior is nice, but from a naive user's point
of view I think one could argue that GNU mv's is more alarming.

This is a contrived example, of course.  I guess what I'm missing here
is a feeling for why it's important for GNU mv to depart from the
standard here, and to break the link-count invariant.  In what sort of
applications are these corner cases important?