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

Previous Next

Full log

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

From: Gian Piero Carrubba <gpiero <at> rm-rf.it>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: Bernhard Voelker <mail <at> bernhard-voelker.de>, 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 14:54:59 +0100

[Message part 1 (text/plain, inline)]

* [Thu, Oct 31, 2013 at 12:12:55PM +0000] Pádraig Brady:
>> On 10/30/2013 01:13 PM, Bernhard Voelker wrote:
>> The changes so far - 12 out of 144 - are:
>>
>>   $ grep "DIFFERENCE in Test: " testit.log | sed 's/^.*: //'
>>   cp -L -l   filelink ...
>>   cp -L -l  --preserve=links filelink ...
>>   cp -L -l -R  filelink ...
>>   cp -L -l -R --preserve=links filelink ...
>>   cp -H -l   filelink ...
>>   cp -H -l  --preserve=links filelink ...
>>   cp -H -l -R  filelink ...
>>   cp -H -l -R --preserve=links filelink ...
>
>So -HL are now honored in this regard
>
>>   cp  -l   dirlink ...
>>   cp  -l  --preserve=links dirlink ...
>>   cp  -l   danglink ...
>>   cp  -l  --preserve=links danglink ...
>
>and by default we don't deref the above.
>
>That all seems consistent with expectations and what we previously 
>discussed.

Not what I would expect, and imho not SUSv3 compliant, either with 
regard to --preserve=links and -R.  More about this later.

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

Oh well, didn't read it like this. My opinion was, and still is even if 
not strong as before, that explicitly using -H/L/preserve=links would 
override that _default_ behaviour.

>I wouldn't be inclined to follow POSIX in that regard.

Oh... I was tweaking a bit the last patch posted by Bernhard in order to 
let it be POSIX compliant (but now I have to add: "for my interpretation 
of POSIX"), but didn't had the time to complete before going to work.  
Will probably finish it up anyway this evening or tomorrow, at this 
point at least for comparing how far we're currently are from "POSIX".
In the meantime please see attached the results for the tests from 
Bernhard. There are a lot more differences in behaviour:

$ fgrep -c "DIFFERENCE in Test: " testit.log
40

but I suspect (I hadn't the time for double checking them) they are all 
correct.

My points in short:

- POSIX (my interpretation): without '-r' the link should be 
  dereferenced, *unless* told otherwise
- POSIX (I think, cannot check now): order of options is important.  In 
  case of conflicting options, the LAST one should be used
- --(no)-preserve=links
  To be honest, it isn't clear to me what it stands for. I have assumed 
  --preserve=links should set DEREF_NEVER and --no-preserve=links should 
  set DEREF_ALWAYS. Anyway I don't particularly like the implementation, 
  as now dereferencing settings are both in x->preserve_links and in 
  x->dereference, some times even with opposite values. And some times a 
  function checks for x->preserve_links and not for x->dereference, or 
  vice versa.
  If it has a different meaning from what I've supposed, I can't 
  understand how it should behave.

Frankly, dereferencing in cp seems a bit more complicated as I first 
supposed.

Ciao,
Gian Piero.

[testit.log.gz (application/octet-stream, attachment)]

Previous Next

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