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


View this message in rfc822 format

From: Gian Piero Carrubba <gpiero <at> rm-rf.it>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: Eric Blake <eblake <at> redhat.com>, Pádraig Brady <P <at> draigBrady.com>, 15173 <at> debbugs.gnu.org
Subject: bug#15173: [cp] --link overrides dereference settings
Date: Thu, 31 Oct 2013 18:26:51 +0100
* [Thu, Oct 31, 2013 at 02:17:24PM +0100] Bernhard Voelker:
>> On October 31, 2013 at 1:12 PM Pádraig Brady <P <at> draigBrady.com> wrote:
>> 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?
[...]
>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.

I don't support this argument. Being it an extension could mean that it 
couldn't _violate_ POSIX but I don't think it is a good reason for being 
_inconsistent_ with POSIX.

>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.

I (strongly) disagree, _especially_ from a user perspective. This is the 
same inconsistence I mentioned before about `cp -r`.

Let's say I run:

cp symlink new

so I get a copy of the _dereferenced_ file.
Mmmh, wait a moment... I don't need a copy, a hardlink would be 
sufficient:

cp -l symlink new

And now I get a hardlink to the _symlink_. Why ? I just wanted to use 
link instead of copy, I didn't mention anything about the dereferencing.  
Why should I have different default behaviours about dereferencing when 
I use _unrelated_ options ?
So now I have to remember that:
- a plain `cp` dereferences
- `cp -l` doesn't
- `cp -r` doesn't
- whatever new GNU option (not -yet- covered by POSIX) could possibly 
  dereference, or not, or just for the command line arguments...

Really Bernhard, from a user perspective this is terrible.

Ciao,
Gian Piero.




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.