Re: mv silently does nothing for hard links

[Jim Meyering]

Paul Eggert <address@hidden> wrote:
> 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).

So far, this is the first glitch I've seen in the POSIX
spec for rename, and I hope it'll be fixed soon.
I certainly don't plan on making a habit of implementing
behavior that runs counter to POSIX specifications.

If it looks like I'm digging a hole, I'm sure you'll let me know :-)
I'm all for standards, and usually side with POSIX, but this looks
like a case where usability would be sacrificed, albeit in a small way.
And since the change to make mv work the way I want is small,
seems safe, and has no impact on performance, I went ahead and made it.

I have raised the issue on the appropriate list.

> 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

Good one.
:-)  contrived indeed  :-)
But, as I'm sure you realize, d/l remains, so mv doesn't actually
destroy both OLD and NEW, but rather ends up invalidating both of
the paths (given as mv arguments) to those files.

> 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.

I hope a naive user never has to figure out what's involved
with hard-linked symlinks in an example like yours.  However,
I think POSIX should allow one to use mv (or rename directly)
to rename a hard link onto another link to the same file.

> 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?

I hope they won't depart forever.
I think the standard should be changed, since it mandates
behavior that is nonintuitive to say the least.

An internals-based argument, like one based on the link-count
invariant, may be enough justification for the current rename
specification (it's not enough for me), but IMHO, it's nowhere near
sufficient justification for imposing such a restriction on mv.

Jim