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

Previous Next

Package: coreutils;

Reported by: Gian Piero Carrubba <gpiero <at> rm-rf.it>

Date: Mon, 4 Nov 2013 23:38:02 UTC

Severity: wishlist

Full log


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

From: Gian Piero Carrubba <gpiero <at> rm-rf.it>
To: Jim Meyering <jim <at> meyering.net>
Cc: 15806 <at> debbugs.gnu.org
Subject: Re: [cp] -R modifies dereferencing settings
Date: Fri, 8 Nov 2013 17:45:40 +0100
* [Tue, Nov 05, 2013 at 12:37:06AM +0100] Gian Piero Carrubba:
>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.

...except that it's not exactly true. If '-r' implied '-P', `cp -rL` 
would dereference and `cp -Lr` would not. Actually they both 
dereference, so a better wording is needed. Something along the line: 
"By default, does not dereference symbolic links in the source".

>= tests/cp/special-f.sh [2]
>This is unexpected. At a first look, the failure should be caused by 
>the following test not being fully inclusive:
>
>    -- src/copy.c:1930
>    else if (! S_ISDIR (dst_sb.st_mode)
>        /* Never unlink dst_name when in move mode.  */
>        && ! x->move_mode
>        && (x->unlink_dest_before_opening
>            || (x->preserve_links && 1 < dst_sb.st_nlink)
>            || (x->dereference == DEREF_NEVER
>                && !  S_ISREG (src_sb.st_mode))
>            ))
>
>I hadn't the time for investigate further, will do in the next days. 
>At the moment, however, I suspect the previous dereference settings was 
>simply masking and underlying issue.

Will diverge to another report, as imho it is a bug by itself.

>[2] A side note about this test. The comment seems to contradict the 
>code:
>
>    -- tests/cp/special-f.sh:28
>    # Without -f, expect it to fail
>    cp -R fifo e || fail=1
>
>As for my impression, it also contradicts POSIX specifications (w/o 
>-f it should fail). Anyway this belongs to another bug report.

mmh, no... a better reading of the specs was enough to understand that 
it should NOT fail, so the test is right (but the comment is 
misleading).

* [Thu, Nov 07, 2013 at 09:27:41AM -0800] Jim Meyering:
>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?

I have to admit I have no strong argument, and I suspect I cannot obtain 
one just by comparing different implementations, given that this 
behaviour is "implementation dependant" (so different implementations 
differ in this regard).

Just for reference, both cp implementations on Solaris 10 dereference:

$ echo TEST > file ; ln -s file link
$ for o in "" -R -r -PR -Pr -RP -rP ; do /usr/bin/cp $o link cp$o ; 
/usr/xpg4/bin/cp $o link cp-xpg4$o ; done
$ ls -liog
     678491 -rw-r--r--   1       5 Nov  8 16:55 cp
     678499 lrwxrwxrwx   1       4 Nov  8 16:55 cp-Pr -> file
     678497 lrwxrwxrwx   1       4 Nov  8 16:55 cp-PR -> file
     678495 -rw-r--r--   1       5 Nov  8 16:55 cp-r
     678493 -rw-r--r--   1       5 Nov  8 16:55 cp-R
     678503 lrwxrwxrwx   1       4 Nov  8 16:55 cp-rP -> file
     678501 lrwxrwxrwx   1       4 Nov  8 16:55 cp-RP -> file
     678492 -rw-r--r--   1       5 Nov  8 16:55 cp-xpg4
     678500 lrwxrwxrwx   1       4 Nov  8 16:55 cp-xpg4-Pr -> file
     678498 lrwxrwxrwx   1       4 Nov  8 16:55 cp-xpg4-PR -> file
     678496 -rw-r--r--   1       5 Nov  8 16:55 cp-xpg4-r
     678494 -rw-r--r--   1       5 Nov  8 16:55 cp-xpg4-R
     678504 lrwxrwxrwx   1       4 Nov  8 16:55 cp-xpg4-rP -> file
     678502 lrwxrwxrwx   1       4 Nov  8 16:55 cp-xpg4-RP -> file
     678489 -rw-r--r--   1       5 Nov  8 16:54 file
     678490 lrwxrwxrwx   1       4 Nov  8 16:54 link -> file

The same is true for AIX 6.1:

$ for o in "" -R -r -P -PR -Pr -RP -rP ; do cp $o link cp$o ; done
$ ls -liog
     32831 -rw-r--r--    1          5 Nov 08 16:53 cp
     32834 lrwxrwxrwx    1          4 Nov 08 16:53 cp-P
     32835 lrwxrwxrwx    1          4 Nov 08 16:53 cp-PR
     32836 lrwxrwxrwx    1          4 Nov 08 16:53 cp-Pr
     32832 -rw-r--r--    1          5 Nov 08 16:53 cp-R
     32837 lrwxrwxrwx    1          4 Nov 08 16:53 cp-RP
     32833 -rw-r--r--    1          5 Nov 08 16:53 cp-r
     32838 lrwxrwxrwx    1          4 Nov 08 16:53 cp-rP
     32829 -rw-r--r--    1          5 Nov 08 16:50 file
     32830 lrwxrwxrwx    1          4 Nov 08 16:50 link

On the other hand, if I recall correctly, the FreeBSD implementation 
acts like the coreutils one (doesn't dereference). Don't know about 
other implementations.

Ciao,
Gian Piero.




This bug report was last modified 11 years and 229 days ago.

Previous Next


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