Re: mv silently does nothing for hard links

[Jim Meyering]

Paul Eggert <address@hidden> wrote:
>> From: Jim Meyering <address@hidden>
>> Date: Tue, 08 Apr 2003 22:46:18 +0200
>>
>> I think that the wording of the POSIX spec for rename is inadequate
>> and should allow `mv A B' to unlink when A and B are hard links that
>> do not refer to the same directory entry.
>
> I could go along with that, but on the other hand the current POSIX
> is what it is.  Perhaps this is case for POSIXLY_CORRECT?

Hi Paul,

I'd prefer to avoid adding another dependency on POSIXLY_CORRECT.
I'd rather arrange to have the POSIX specification for rename fixed,
or barring that, just document and live with the mv incompatibility.
I don't see why anyone would want rename/mv to have the specified
behavior.

>> The rename rationale seems to support that interpretation, and
>> thus seems to be inconsistent with the specification.
>
> The rename rationale says: ``The specification that if old and new
> refer to the same file is intended to guarantee that `rename("x",
> "x")' does not remove the file.''  I take this to mean something like:
>
>   `rename(FOO,BAR)' must do nothing if FOO and BAR are the same file;
>   therefore, `rename' can't remove a file.

But in your wording, it looks like there are two separate variable
names, FOO and BAR, which *may* have the same value.  Theirs makes it
clear there is only one value, used both as OLD and as NEW.  Also,
you've changed their `the file', which implies there is only one
thing that might be unlinked, to `a file', which is more consistent
with the possibility of there being more than one unlink target.

I prefer Andries' proposed wording:

  http://www.opengroup.org/austin/mailarchives/austin-review-l/msg00048.html

    Change lines 26148-26149 to:
    If the old argument and the new argument are pathnames with
    the same final element, and these pathnames refer to the same file,
    and their path prefixes (the predecessors of the respective
    final elements, as defined in 2.3.6) refer to the same directory,
    the rename() function shall return successfully and perform no
    other action.

> But this assertion is true regardless of whether one substitutes "the
> same directory entry" for "the same file".  It is true that the
> assertion is sharper with the substitution, but still I have to wonder
> what the intent was.  (The fact that the POSIX rationale does not use
> proper English grammar doesn't help much.)
>
>> Besides, the POSIX-mandated behavior doesn't make sense :-)
>
> Did you see Bruce Evans's comments in
> <http://www.opengroup.org/sophocles/show_mail.tpl?source=L&listname=austin-group-l&id=5158>?
> He said that a nice property of POSIX rename() is that it never
> changes the link count.  "Never changes the link count" is one way to
> interpret the "does not remove the file" of the POSIX rationale for
> `rename'.

Yes, I saw that.  Maintaining such an invariant may be nice from
an internals standpoint, but the net effect would be that rename,
and hence mv too, have non-intuitive behavior, albeit in a rather
unusual corner case.

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.  IMHO, that is
the important point.  It certainly has been a guiding tenet in the
implementation of GNU mv and cp.  They do what the user expects,
as long as doing so doesn't destroy what is initially called the
SOURCE file.

> Also, Bruce Evans wrote that GNU/Linux rename() was changed to conform
> to POSIX 10 years ago.  It would be a bit disconcerting if GNU/Linux
> rename() conformed to POSIX, but GNU mv did not.

It wouldn't be disconcerting to me, since I think that the POSIX spec
for rename is unnecessarily restrictive.

Jim