emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#15579: closed (Bug in documentation on cp)


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#15579: closed (Bug in documentation on cp)
Date: Thu, 10 Oct 2013 09:14:01 +0000

Your message dated Thu, 10 Oct 2013 10:13:11 +0100
with message-id <address@hidden>
and subject line Re: bug#15579: Bug in documentation on cp
has caused the debbugs.gnu.org bug report #15579,
regarding Bug in documentation on cp
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
15579: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15579
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: Bug in documentation on cp Date: Thu, 10 Oct 2013 04:02:14 +0200 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130922 Icedove/17.0.9
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!



--- End Message ---
--- Begin Message --- Subject: Re: bug#15579: Bug in documentation on cp Date: Thu, 10 Oct 2013 10:13:11 +0100 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2
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.



--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]