bug#15806: [cp] -R modifies dereferencing settings

[Jim Meyering]

On Mon, Nov 4, 2013 at 3:37 PM, Gian Piero Carrubba <address@hidden> 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?