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

Previous Next

Full log

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

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