GNU bug report logs - #10686
mv: moving hardlink of a softlink to the softlink does nothing

Previous Next

Full log

Message #50 received at 10686 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Eric Blake <eblake <at> redhat.com>
Cc: Bernhard Voelker <mail <at> bernhard-voelker.de>, 10686 <at> debbugs.gnu.org
Subject: Re: bug#10686: mv: moving hardlink of a softlink to the softlink does
	nothing
Date: Sun, 12 Feb 2012 14:14:40 +0100

Eric Blake wrote:
> On 02/11/2012 04:23 AM, Jim Meyering wrote:
>> +++ b/NEWS
...
>> +  "mv A B" could succeed, yet A would remain.  This would happen only when
>> +  both A and B were hard links to the same symlink, and with a kernel for
>> +  which rename("A","B") would do nothing and return 0.  Now, in this
>> +  unusual case, mv does not call rename, and instead simply unlinks A.
>
> You make it sound like a kernel where rename("A","B") returns 0 is
> unusual;

Thank you for the review and suggestions.

Such kernels *should* be unusual.  This rename-is-sometimes-a-no-op
exception makes it hard to use rename in an application that must
reliably produce results that make sense even to people who don't
care what inodes and invariants are.

> on the contrary, that is normal, since it is the POSIX-mandated
> behavior for kernels.  What is unusual is having two hardlinks to the
> same symlink.  Maybe we should reword this slightly, to attach the
> "unusual" modifier to the correct phrase, or even take "kernel" out of
> the description:
>
> "mv A B" could succeed, yet A would remain.  This would only happen
> in the unusual case when both A and B were hard links to the same
> symlink, due to the standard behavior of rename.  Now, mv recognizes
> the case and simply unlinks A.

This is the NEWS file, where we prefer to stick to the facts, but I
feel I have to make a small statement, so have adjusted it like this:

  "mv A B" could succeed, yet A would remain.  This would happen only when
  both A and B were hard links to the same symlink, and with a kernel for
  which rename("A","B") does nothing and returns 0 (POSIX mandates this
  surprising rename no-op behavior).  Now, mv handles this case by skipping
  the usually-useless rename and simply unlinking A.


>> +++ b/tests/mv/symlink-onto-hardlink-to-self
>> @@ -0,0 +1,56 @@
>> +#!/bin/sh
>> +# Demonstrate that when moving a symlink onto a hardlink-to-that-symlink, the
>> +# source symlink is removed.  Depending on your kernel (e.g., with the linux
>> +# kernel), prior to coreutils-8.16, the mv would successfully perform a no-op.
>
> Again, this is the POSIX-required behavior of ALL kernels, and not
> something special to Linux.

NetBSD 5.1 has the sensible kernel rename behavior, i.e.,
what one would expect in the absence of standardized legacy:

    netbsd$ : > f; ln f g; perl -e 'rename qw(f g) or die "$!"'; ls f g
    ls: cannot access f: No such file or directory
    g
    [Exit 2]

Programs like mv should not have to jump through hoops like copy.c's
same_file_ok function just to avoid the surprising (nonsensical, to most)
behavior of the standardized rename syscall.

I adjusted that comment, too, and pushed the result:

# Demonstrate that when moving a symlink onto a hardlink-to-that-symlink, the
# source symlink is removed.  Depending on your kernel (e.g., Linux, Solaris,
# but not NetBSD), prior to coreutils-8.16, the mv would successfully perform
# a no-op.  I.e., surprisingly, mv s1 s2 would succeed, yet fail to remove s1.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.