GNU bug report logs - #15579
Bug in documentation on cp

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 15579 in the body.
You can then email your comments to 15579 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: hobo pope <hobo-pope <at> insiberia.net>
To: bug-coreutils <at> gnu.org
Subject: Bug in documentation on cp
Date: Thu, 10 Oct 2013 04:02:14 +0200

Dear Team,


I think I might have found the following bug in info cp [documentation]

The option --preserve= offers: " `links'
Preserve in the destination files any links between
corresponding source files. Note that with `-L' or `-H',
this option can convert symbolic links to hard links…

I've played around a bit, but got different results on "Note that with 
`-L' or `-H', this option can convert symbolic links to hard links"

Using --preserve=links with[out] the option -H or -L I get hardlinked 
files.

This happend with GNU coreutils 8.12.197-032bb.

I work on Crunchbang Linux [Debian 7], where uname -a -> 3.2.0-4-amd64 
#1 SMP Debian 3.2.46-1+deb7u1 x86_64 GNU/Linux



I've posted two screenshots of this online:

with(out) the -H option: http://i.stack.imgur.com/eb8rf.png
with(out) the -L option: http://i.stack.imgur.com/U4OUV.png

In both cases, I get hard linked files - which is nice, but doesn't 
accord to the documentation.

I didn't wanted to post the images as attachment because I don't know if 
this is appreciated, but can transmit them if this is helpful.

I hope this helped and all the best with a hearfelt thank you for all 
the good work!




A satisfied GNU/Linux user

P.S.: A short reply if this was just a misunderstanding from my side or 
a real bug would be very appreciated. Thank you in advance for all your 
efforts!

Message #10 received at 15579-done <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: hobo pope <hobo-pope <at> insiberia.net>
Cc: 15579-done <at> debbugs.gnu.org
Subject: Re: bug#15579: Bug in documentation on cp
Date: Thu, 10 Oct 2013 10:13:11 +0100

On 10/10/2013 03:02 AM, hobo pope wrote:
> Dear Team,
> 
> 
> I think I might have found the following bug in info cp [documentation]
> 
> The option --preserve= offers: " `links'
> Preserve in the destination files any links between
> corresponding source files. Note that with `-L' or `-H',
> this option can convert symbolic links to hard links…
> 
> I've played around a bit, but got different results on "Note that with `-L' or `-H', this option can convert symbolic links to hard links"
> 
> Using --preserve=links with[out] the option -H or -L I get hardlinked files.
> 
> This happend with GNU coreutils 8.12.197-032bb.
> 
> I work on Crunchbang Linux [Debian 7], where uname -a -> 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1+deb7u1 x86_64 GNU/Linux
> 
> 
> 
> I've posted two screenshots of this online:
> 
> with(out) the -H option: http://i.stack.imgur.com/eb8rf.png
> with(out) the -L option: http://i.stack.imgur.com/U4OUV.png
> 
> In both cases, I get hard linked files - which is nice, but doesn't accord to the documentation.
> 
> I didn't wanted to post the images as attachment because I don't know if this is appreciated, but can transmit them if this is helpful.
> 
> I hope this helped and all the best with a hearfelt thank you for all the good work!
> 
> 
> 
> 
> A satisfied GNU/Linux user
> 
> P.S.: A short reply if this was just a misunderstanding from my side or a real bug would be very appreciated. Thank you in advance for all your efforts!

The docs are a bit terse here.
The main issue is that -a implies -d and that implies --no-dereference
which is required to get your commands to work as expected.
I.E. --no-dereference is required to stop cp implicitly
following symlinks in the source.

To verify and split out the detail being demonstrated here:

$ mkdir links; : > a; ln -s a b;

Here we see that -d overrides -H as it comes after.
Therefore we will not dereference symlinks in the first place.

$ rm links/*; cp -H -d a b links
$ l links/
lrwxrwxrwx. 1 padraig 1 Oct 10 09:37 b ▪▶ a
-rw-rw-r--. 1 padraig 0 Oct 10 09:37 a

Here we see that -H is now honored as it comes last,
and therefore symlinks are followed in the source,
resulting in hardlinks in the destination.

$ rm links/*
$ rm links/*; cp -d -H a b links
$ l links
-rw-rw-r--. 2 padraig 0 Oct 10 09:37 b
-rw-rw-r--. 2 padraig 0 Oct 10 09:37 a

I'll make the docs a bit more explicit with the following:

diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index b273627..aeed4ca 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -8257,9 +8257,11 @@ $ mkdir c; : > a; ln -s a b; cp -aH a b c; ls -i1 c
 @noindent
 Note the inputs: @file{b} is a symlink to regular file @file{a},
 yet the files in destination directory, @file{c/}, are hard-linked.
-Since @option{-a} implies @option{--preserve=links}, and since @option{-H}
-tells @command{cp} to dereference command line arguments, it sees two files
-with the same inode number, and preserves the perceived hard link.
+Since @option{-a} implies @option{--no-dereference} it would copy the symlink,
+but the later @option{-H} tells @command{cp} to dereference the command line
+arguments where it then sees two files with the same inode number.
+Then the @option{--preserve=links} option also implied by @option{-a}
+will preserve the perceived hard link.

thanks,
Pádraig.

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

From: Bob Proulx <bob <at> proulx.com>
To: hobo pope <hobo-pope <at> insiberia.net>
Cc: 15579 <at> debbugs.gnu.org
Subject: Re: bug#15579: Bug in documentation on cp
Date: Thu, 10 Oct 2013 14:42:47 -0600

hobo pope wrote:
> I've posted two screenshots of this online:
> 
> with(out) the -H option: http://i.stack.imgur.com/eb8rf.png
> with(out) the -L option: http://i.stack.imgur.com/U4OUV.png
> ...
> I didn't wanted to post the images as attachment because I don't
> know if this is appreciated, but can transmit them if this is
> helpful.

Thank you for posting a URL instead of attaching the images.  That was
more friendly than attaching the images.  Except!  There is always an
except.  :-)

Except those are images of text.  The best thing is simply to post the
text.  It is almost never appropriate to post images.  Images of text
are particularly bad.  There is never a reason to post images of
text.  Simply post the text itself.

When reporting test cases it is always best to cut and paste the text
of the case verbatim.  That way the entire thing is small.  It is then
preserved in the archive.  The text of the text is what is desired.
With that we can see the test case easily.  If the test case is well
done then we can cut and paste the test case ourselves out of the mail
and into our shell for testing.

Bob

Previous Next

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