GNU bug report logs - #15173
[cp] --link overrides dereference settings

Previous Next

Package: coreutils;

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

Date: Fri, 23 Aug 2013 21:55:02 UTC

Severity: normal

Tags: fixed

Merged with 23120

Done: Bernhard Voelker <mail <at> bernhard-voelker.de>

Bug is archived. No further changes may be made.

Full log


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

From: Pádraig Brady <P <at> draigBrady.com>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: Gian Piero Carrubba <gpiero <at> rm-rf.it>, Eric Blake <eblake <at> redhat.com>,
 15173 <at> debbugs.gnu.org
Subject: Re: bug#15173: [cp] --link overrides dereference settings
Date: Thu, 31 Oct 2013 16:47:32 +0000
On 10/31/2013 01:17 PM, Bernhard Voelker wrote:
>> On October 31, 2013 at 1:12 PM Pádraig Brady <P <at> draigBrady.com> wrote:
>> That all seems consistent with expectations and what we previously discussed.
>>
>> But...
>>
>> I've just now read POSIX for cp, and it states:
>>
>>   "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."
>>
>> This suggests that -HL should only be significant with -R ?
>> That is a bit surprising TBH. What do you think Eric?
>>
>> It also suggests that we should hardlink to a symlink only with -P,
>> i.e. that we should AT_SYMLINK_FOLLOW unless -P is specified ?
>> That's also a bit surprising, given that POSIX for ln states
>> that it's implementation defined what's done if neither -P or -L is specified.
>> I wouldn't be inclined to follow POSIX in that regard.
> 
> I don't read the POSIX spec that way: there are 2 things to consider:
> a) POSIX doesn't say a word about hard links, and
> b) the -l,--link option is a GNU extension to conveniently
>    copy files or trees by creating hard links (only).
> 
> I.e. if someone uses -l, then the POSIX semantics does not
> apply anymore because we do not copy anymore.  Whether the
> ln(1) specification does apply more here is another question.
> 
> Therefore, I think GNU cp(1) should do what makes most sense
> for the user - depending on -LPH or none being used.  With the
> proposed patch, I think we're getting a bit closer to that.

OK cool. With that cp and ln will be more consistent with each other anyway.

thanks,
Pádraig.





This bug report was last modified 6 years and 206 days ago.

Previous Next


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