bug#10686: mv: moving hardlink of a softlink to the softlink does nothing

Playing around with the latest mv checkin,
I noticed another corner case:

Create a file 'f', a symlink 'l' to it, and
then a hardlink 's' to that symlink:

  $ touch f && ln -s f l && ln l s && ls -ogi
  total 0
  6444 -rw-r--r-- 1 0 Feb  1 08:52 f
  6462 lrwxrwxrwx 2 1 Feb  1 08:52 l -> f
  6462 lrwxrwxrwx 2 1 Feb  1 08:52 s -> f

Trying to mv the hardlink over the symlink seems to succeed:

  $ ~/git/coreutils/src/mv s l

... but the name 's' was not unlinked:

  $ ls -ogi
  total 0
  6444 -rw-r--r-- 1 0 Feb  1 08:52 f
  6462 lrwxrwxrwx 2 1 Feb  1 08:52 l -> f
  6462 lrwxrwxrwx 2 1 Feb  1 08:52 s -> f

Using the -v option looks also normal, but is a nop:

  $ ~/git/coreutils/src/mv -v s l
  ‘s’ -> ‘l’
  $ ls -ogi
  total 0

bug#10639: BUG REPORT coreutils-8.15 Solaris 10 64bit

On 01/30/2012 07:01 PM, JONES, BILL wrote:
> those are vxfs.

Thanks, can you please try the attached patch?
You can apply it by running the shell commands:

  cd lib
  patch < vxfs-patch.txt

I'll CC: this to bug-gnulib as it appears to be a Gnulib bug.

Thanks.

acl: fix infinite loop on Solaris 10 + vxfs
Problem reported by Bill Jones in
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10639>.
* lib/acl-internal.h: Include <limits.h>.
(MIN): New macro.
* lib/copy-acl.c (qcopy_acl): Don't object if we get fewer ACL
entries than we originally counted; perhaps some were removed
as we were running, or perhaps we can count but not get.
Check for size-calculation overflow.
Avoid need for dynamic allocation if possible.
* lib/file-has-acl.c (file_has_acl): Likewise.
* lib/set-mode-acl.c (qset_acl): Likewise.
diff --git a/lib/acl-internal.h b/lib/acl-internal.h
index 88e5e45..64701b2 100644
--- a/lib/acl-internal.h
+++ b/lib/acl-internal.h

bug#10639: BUG REPORT coreutils-8.15 Solaris 10 64bit

Paul Eggert wrote:
> Thanks, can you please try the attached patch?

I find it overkill to change the code for HP-UX and NonStop systems
when the report is about Solaris. Also I think the structure of the loop
is not the problem; it is the code's reaction to
  acl("x", ACE_GETACL, 4, 0x3432A16E0)            Err#-1

Please, can you also try this patch?

2012-02-01  Bruno Haible  <bruno <at> clisp.org>

        * lib/file-has-acl.c (file_has_acl) [Solaris]: Treat a failing
        acl()/facl() call for ACE_GETACL like a failing call for ACE_GETACLCNT.
        * lib/set-mode-acl.c (qset_acl) [Solaris]: Likewise.
        * lib/copy-acl.c (qcopy_acl)[Solaris]: Likewise.

--- lib/copy-acl.c.orig	Wed Feb  1 11:15:51 2012
+++ lib/copy-acl.c	Wed Feb  1 11:10:55 2012
@@ -235,10 +235,22 @@
           return -2;
         }

-      if ((source_desc != -1
-           ? facl (source_desc, ACE_GETACL, ace_count, ace_entries)
-           : acl (src_name, ACE_GETACL, ace_count, ace_entries))
-          == ace_count)
+      ret = (source_desc != -1

bug#10686: mv: moving hardlink of a softlink to the softlink does nothing

On 02/01/2012 09:21 AM, Bernhard Voelker wrote:

>   $ touch f && ln -s f l && ln l s && ls -ogi
>   total 0
>   6444 -rw-r--r-- 1 0 Feb  1 08:52 f
>   6462 lrwxrwxrwx 2 1 Feb  1 08:52 l -> f
>   6462 lrwxrwxrwx 2 1 Feb  1 08:52 s -> f
> 
> Trying to mv the hardlink over the symlink seems to succeed:
> 
>   $ ~/git/coreutils/src/mv s l
> 
> ... but the name 's' was not unlinked:

...

> That behaviour didn't change at least since version 7.1
> (on openSuSE-11.3), but back in the earlier days in 5.93
> (SLES-10.3), 's' disappeared as expected:

Hmm, looks like commit
   f1d1ee91217d08527c6bf7682987339e38116268
introduced this in 2006.

Have a nice day,
Berny

bug#10686: mv: moving hardlink of a softlink to the softlink does nothing

Bernhard Voelker wrote:
> Playing around with the latest mv checkin,
> I noticed another corner case:
>
> Create a file 'f', a symlink 'l' to it, and
> then a hardlink 's' to that symlink:
>
>   $ touch f && ln -s f l && ln l s && ls -ogi
>   total 0
>   6444 -rw-r--r-- 1 0 Feb  1 08:52 f
>   6462 lrwxrwxrwx 2 1 Feb  1 08:52 l -> f
>   6462 lrwxrwxrwx 2 1 Feb  1 08:52 s -> f

Hi Bernhard,
Thanks for the report.

Here, you've already gotten into questionable territory, since the
idea of a hard link to a symbolic link is not standardized.
For example, on FreeBSD 9.0, you cannot even create one:
(instead, it hard-links the referent of the symlink)

    freebsd$ touch f && ln -s f l && ln l s && ls -ogi f l s
    1587047 -rw-r--r-- 2 0 Feb  1 04:58 f
    1587100 lrwxr-xr-x 1 1 Feb  1 04:58 l -> f
    1587047 -rw-r--r-- 2 0 Feb  1 04:58 s

> Trying to mv the hardlink over the symlink seems to succeed:
>
>   $ ~/git/coreutils/src/mv s l
>

bug#10686: mv: moving hardlink of a softlink to the softlink does nothing

On 02/01/2012 01:47 PM, Jim Meyering wrote:
> Bernhard Voelker wrote:
>> Playing around with the latest mv checkin,
>> I noticed another corner case:
>>
>> Create a file 'f', a symlink 'l' to it, and
>> then a hardlink 's' to that symlink:
>>
>>   $ touch f && ln -s f l && ln l s && ls -ogi
>>   total 0
>>   6444 -rw-r--r-- 1 0 Feb  1 08:52 f
>>   6462 lrwxrwxrwx 2 1 Feb  1 08:52 l -> f
>>   6462 lrwxrwxrwx 2 1 Feb  1 08:52 s -> f
> 
> Hi Bernhard,
> Thanks for the report.
> 
> Here, you've already gotten into questionable territory, since the
> idea of a hard link to a symbolic link is not standardized.
> For example, on FreeBSD 9.0, you cannot even create one:
> (instead, it hard-links the referent of the symlink)
> 
>     freebsd$ touch f && ln -s f l && ln l s && ls -ogi f l s
>     1587047 -rw-r--r-- 2 0 Feb  1 04:58 f
>     1587100 lrwxr-xr-x 1 1 Feb  1 04:58 l -> f
>     1587047 -rw-r--r-- 2 0 Feb  1 04:58 s
> 
>> Trying to mv the hardlink over the symlink seems to succeed:
>>
>>   $ ~/git/coreutils/src/mv s l

bug#10686: mv: moving hardlink of a softlink to the softlink does nothing

Bernhard Voelker wrote:
...
> well, if it's not standardized (yet), then I agree with you that we
> should choose the simpler b) alternative.
>
> Do you think it's work thinking about the -f case?
>
>   $ ~/git/coreutils/src/mv -f s l
>   /home/berny/git/coreutils/src/mv: ‘s’ and ‘l’ are the same file

mv's -f option is unrelated to this case.
It relates solely to controlling whether one is prompted
due to permissions or -i.

From 'info mv's description of the common case (no options):

       If a destination file exists but is normally unwritable, standard
    input is a terminal, and the `-f' or `--force' option is not given,
    `mv' prompts the user for whether to replace the file.  (You might own
    the file, or have write permission on its directory.)  If the response
    is not affirmative, the file is skipped.

Yes, it is unfortunate that the standards-imposed semantics
of -f is different from what we'd expect.

> The info pages are not quite clear in which cases mv tries to
> overwrite the destination. Usually, I am tempted to think that
> a "--force" will "just do it" - regardless of data loss.
> But in this case, mv "just does not" and the only thing left
> is to rm that hardlink.

bug#10686: mv: moving hardlink of a softlink to the softlink does nothing

On 02/01/2012 03:02 PM, Jim Meyering wrote:
> Bernhard Voelker wrote:
> ...
>> well, if it's not standardized (yet), then I agree with you that we
>> should choose the simpler b) alternative.
>>
>> Do you think it's work thinking about the -f case?
>>
>>   $ ~/git/coreutils/src/mv -f s l
>>   /home/berny/git/coreutils/src/mv: ‘s’ and ‘l’ are the same file
> 
> mv's -f option is unrelated to this case.
> It relates solely to controlling whether one is prompted
> due to permissions or -i.
> 
> From 'info mv's description of the common case (no options):
> 
>        If a destination file exists but is normally unwritable, standard
>     input is a terminal, and the `-f' or `--force' option is not given,
>     `mv' prompts the user for whether to replace the file.  (You might own
>     the file, or have write permission on its directory.)  If the response
>     is not affirmative, the file is skipped.
> 
> 
> Yes, it is unfortunate that the standards-imposed semantics
> of -f is different from what we'd expect.
> 

> If the above is still not clear, please suggest how to improve it.

bug#10686: mv: moving hardlink of a softlink to the softlink does nothing

On 02/01/2012 05:47 AM, Jim Meyering wrote:
> Bernhard Voelker wrote:
>> Playing around with the latest mv checkin,
>> I noticed another corner case:
>>
>> Create a file 'f', a symlink 'l' to it, and
>> then a hardlink 's' to that symlink:
>>
>>   $ touch f && ln -s f l && ln l s && ls -ogi
>>   total 0
>>   6444 -rw-r--r-- 1 0 Feb  1 08:52 f
>>   6462 lrwxrwxrwx 2 1 Feb  1 08:52 l -> f
>>   6462 lrwxrwxrwx 2 1 Feb  1 08:52 s -> f
> 
> Hi Bernhard,
> Thanks for the report.
> 
> Here, you've already gotten into questionable territory, since the
> idea of a hard link to a symbolic link is not standardized.

Actually, POSIX 2008 _did_ standardize the notion of a hard link to a
symlink, thanks to linkat().

> For example, on FreeBSD 9.0, you cannot even create one:

That's a POSIX-compliance bug in FreeBSD.  In that case, the best we can
do is emulate it by creating a new symlink with identical contents and
owner and as much of the timestamp as lutimens will allow.

> 

bug#10686: mv: moving hardlink of a softlink to the softlink does nothing

Eric Blake wrote:

> On 02/01/2012 05:47 AM, Jim Meyering wrote:
>> Bernhard Voelker wrote:
>>> Playing around with the latest mv checkin,
>>> I noticed another corner case:
>>>
>>> Create a file 'f', a symlink 'l' to it, and
>>> then a hardlink 's' to that symlink:
>>>
>>>   $ touch f && ln -s f l && ln l s && ls -ogi
>>>   total 0
>>>   6444 -rw-r--r-- 1 0 Feb  1 08:52 f
>>>   6462 lrwxrwxrwx 2 1 Feb  1 08:52 l -> f
>>>   6462 lrwxrwxrwx 2 1 Feb  1 08:52 s -> f
>>
>> Hi Bernhard,
>> Thanks for the report.
>>
>> Here, you've already gotten into questionable territory, since the
>> idea of a hard link to a symbolic link is not standardized.
>
> Actually, POSIX 2008 _did_ standardize the notion of a hard link to a
> symlink, thanks to linkat().
>
>> For example, on FreeBSD 9.0, you cannot even create one:
>
> That's a POSIX-compliance bug in FreeBSD.  In that case, the best we can
> do is emulate it by creating a new symlink with identical contents and
> owner and as much of the timestamp as lutimens will allow.