GNU bug report logs - #15806
[cp] -R modifies dereferencing settings

Previous Next

Full log

View this message in rfc822 format

From: Jim Meyering <jim <at> meyering.net>
To: Gian Piero Carrubba <gpiero <at> rm-rf.it>
Cc: 15806 <at> debbugs.gnu.org
Subject: bug#15806: [cp] -R modifies dereferencing settings
Date: Thu, 7 Nov 2013 09:27:41 -0800

On Mon, Nov 4, 2013 at 3:37 PM, Gian Piero Carrubba <gpiero <at> rm-rf.it> wrote:
> Severity: wishlist
>
> Please Cc: me as I'm not subscribed.
>
> POSIX.1-2008 (ed. 2013) [0] states:
>
>     If source_file is a file of type symbolic link:
>
>     If the -R option was not specified, cp shall take actions based on
>     the type and contents of the file referenced by the symbolic link,
>     and not by the symbolic link itself, unless the -P option was
>     specified.
>
> So far, so good. As far as I know, coreutils' cp fully respect this.
>
>     If the -R option was specified:
>
>     If none of the options -H, -L, nor -P were specified, it is
>     unspecified which of -H, -L, or -P will be used as a default.
>
> Somewhere in the past, coreutils team has opted for using '-P' (DEREF_NEVER)
> in this case.  Anyway this leads to an inconsistence in the behaviour of cp:
>
>     $ touch file ; ln -s file symlink ; for o in "" -r ; do cp $o
>     symlink cp$o ; done ; ls -liog
>     total 0
>     8224776 -rw-r--r-- 1 0 Nov  4 23:15 cp
>     8224777 lrwxrwxrwx 1 4 Nov  4 23:15 cp-r -> file
>     8224774 -rw-r--r-- 1 0 Nov  4 23:15 file
>     8224775 lrwxrwxrwx 1 4 Nov  4 23:15 symlink -> file
>
> What wrong with it ? The problem is that we got a modified dereference
> setting just by using '--recursive', an unrelated option. Moreover,
> recursion and dereferencing are orthogonal features and there's no reason
> one should imply the other.
>
> As for my opinion, there are three possibilities for, at least, reduce this
> perceived inconsistency.
> 1. leave `cp -R` acting as it currently does...
>
> ...but properly document it. The texinfo doc already cites this behaviour,
> but both the man page and the help (imo, the two most used  sources while
> searching for an option) don't. I would suggest adding "Implies
> '--no-dereference'" to the description of the -r/-R option.

Thanks for your report and the patch.

My first reaction is that it would take a strong argument to justify
changing the existing semantics. Have you compared the semantics
of any other cp implementations?

Previous Next

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