GNU bug report logs - #15173
[cp] --link overrides dereference settings

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Gian Piero Carrubba <gpiero <at> rm-rf.it>
Subject: bug#15173: closed (Re: bug#15173: [cp] --link overrides
 dereference settings)
Date: Thu, 07 Nov 2013 23:00:04 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#15173: [cp] --link overrides dereference settings

which was filed against the coreutils package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 15173 <at> debbugs.gnu.org.

-- 
15173: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15173
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Gian Piero Carrubba <gpiero <at> rm-rf.it>
Cc: Eric Blake <eblake <at> redhat.com>,
 Pádraig Brady <P <at> draigBrady.com>,
 Jim Meyering <jim <at> meyering.net>, 15173-done <at> debbugs.gnu.org
Subject: Re: bug#15173: [cp] --link overrides dereference settings
Date: Thu, 07 Nov 2013 23:59:28 +0100

On 11/07/2013 03:09 PM, Gian Piero Carrubba wrote:
> * [Thu, Nov 07, 2013 at 10:14:05AM +0000] Pádraig Brady:
>> I.E. IMHO your current patch is fine and good.
> 
> Fair enough. In this case please also update the documentation.

Good idea, thanks.
I pushed it in your name (together with Padraig's notes regarding
NEWS and the test case):
http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=bf6bf52d

I'm hereby marking the bug as done.

Thanks again.

Have a nice day,
Berny

[Message part 3 (message/rfc822, inline)]

From: Gian Piero Carrubba <gpiero <at> rm-rf.it>
To: bug-coreutils <at> gnu.org
Subject: [cp] --link overrides dereference settings
Date: Fri, 23 Aug 2013 23:40:34 +0200

[Message part 4 (text/plain, inline)]

Please keep me in Cc: as I'm not subscribed.

I failed to find references to discussions about this (intended?) 
behaviour, so I'm filing this report. Please forgive me if I've missed 
something elementary.

$ echo testfile > file; ln -s file link; opts="-l -Ll -Hl";
for o in $opts; do cp $o link cp${o}; done;
ls -li

total 4
3358742 lrwxrwxrwx 4 gpiero gpiero 4 Aug 23 22:27 cp-Hl -> file
3358742 lrwxrwxrwx 4 gpiero gpiero 4 Aug 23 22:27 cp-Ll -> file
3358742 lrwxrwxrwx 4 gpiero gpiero 4 Aug 23 22:27 cp-l -> file
3358741 -rw-r--r-- 1 gpiero gpiero 9 Aug 23 22:27 file
3358742 lrwxrwxrwx 4 gpiero gpiero 4 Aug 23 22:27 link -> file

I would have expected both 'cp-Hl' and 'cp-Ll' to be hardlinked to 
'file', not to 'link'.

$ cp --version | head -n1
cp (GNU coreutils) 8.21

$ uname -a
Linux caimano 3.10-2-amd64 #1 SMP Debian 3.10.5-1 (2013-08-07) x86_64 GNU/Linux

$ readlink -f /lib/x86_64-linux-gnu/libc.so.6                                                               
/lib/x86_64-linux-gnu/libc-2.17.so

A tentative draft patch is attached. It still lacks unit tests and a way 
to determine if the implementation of linkat() supports flags.
But most of all, please note that I'm not fully aware of the 
implications (including portability issues) of such a change.

AFAICS, at least in one case the patch changes the behaviour of cp:

$ echo testfile > file; ln -s file link;
cp -l link cp-l.old; ../src/cp -l link cp-l.new;
ls -li

total 8
8912975 -rw-r--r-- 2 gpiero gpiero 9 Aug 23 22:58 cp-l.new
8913010 lrwxrwxrwx 2 gpiero gpiero 4 Aug 23 22:58 cp-l.old -> file
8912975 -rw-r--r-- 2 gpiero gpiero 9 Aug 23 22:58 file
8913010 lrwxrwxrwx 2 gpiero gpiero 4 Aug 23 22:58 link -> file

This is caused by the following code:

$ tail -n+1135 src/cp.c | head -n8
  if (x.dereference == DEREF_UNDEFINED)
    {
      if (x.recursive)
        /* This is compatible with FreeBSD.  */
        x.dereference = DEREF_NEVER;
      else
        x.dereference = DEREF_ALWAYS;
    }

Not sure why this snippet is there[0], but it seems to me that it leads 
to inconsistent behaviour:

$ echo testfile > file; ln -s file link;
cp link cp; cp -r link cp-r;
ls -li

total 8
3358743 -rw-r--r-- 1 gpiero gpiero 9 Aug 23 23:06 cp
3358744 lrwxrwxrwx 1 gpiero gpiero 4 Aug 23 23:06 cp-r -> file
3358741 -rw-r--r-- 1 gpiero gpiero 9 Aug 23 23:06 file
3358742 lrwxrwxrwx 1 gpiero gpiero 4 Aug 23 23:06 link -> file

I think it is counterintuitive that '--recursive' had effects on the 
referentiation of the link.[1]

Anyway, given that x.dereference is set to DEREF_ALWAYS, I think the 
modified behaviour of `cp -l` could be considered correct.

Thanks,
Gian Piero.

[0] I suspect this is for backward compatibility. In principle, I think 
DEREF_UNDEF should always set DEREF_NEVER, but this change would modify 
a common, and well spread, behaviour.

[1] The same stands for '--link', as demonstrated in the first example, 
when 'cp-l' has been created as a hardlink to the symlink (even if for 
different reasons: in that case DEREF_ALWAYS was in place, but linkat() 
didn't follow the symlink).

[draft.patch (text/x-diff, attachment)]

Previous Next

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