GNU bug report logs -
#15173
[cp] --link overrides dereference settings
Previous Next
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 #38 received at 15173 <at> debbugs.gnu.org (full text, mbox):
* [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 207 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.