bug#15173: [cp] --link overrides dereference settings

[Pádraig Brady]

On 11/04/2013 11:02 PM, Bernhard Voelker wrote:
> On 11/04/2013 10:37 AM, Pádraig Brady wrote:
>> On 11/04/2013 12:48 AM, Bernhard Voelker wrote:
>>> It got late again. I'll have a look tomorrow again - maybe there
>>> are no side effects with the following:
>>>
>>> diff --git a/src/cp.c b/src/cp.c
>>> index 7bc8630..78c0a04 100644
>>> --- a/src/cp.c
>>> +++ b/src/cp.c
>>> @@ -1135,7 +1135,7 @@ main (int argc, char **argv)
>>>
>>>    if (x.dereference == DEREF_UNDEFINED)
>>>      {
>>> -      if (x.recursive)
>>> +      if (x.recursive && ! x.hard_link)
>>>          /* This is compatible with FreeBSD.  */
>>>          x.dereference = DEREF_NEVER;
>>>        else
>>
>> Yes I didn't consider -R in the table as I don't see any reason
>> for it to behave differently when -l is specified (and -l aplies
>> neither to POSIX or BSD (comment)).  So the above adjustment
>> looks correct to me.
> 
> Indeed, that adjustment seems to be the right one - finally. ;-)
> I have added it to the patch as well as a new test case. I've added
> a "Co-authored-by:"-me line for that.
> 
> @Gian: please note that we use "double-blank after-dot" format in
> comments. I've fixed that for you.
> 
> The patch passes make check and syntax-check.
> 
> I've also attached the test result cp-8.21 versus the new one.
> These are the differences (I leave out the --preserve=links cases
> as these are also affected but unrelated):
> 
> COMMAND                   | 8.21 | NEW
> cp  -l   filelink ...     |  S   |  T
> cp  -l -R  filelink ...   |  S   |  T
> cp -L -l   filelink ...   |  S   |  T
> cp -L -l -R  filelink ... |  S   |  T
> cp -H -l   filelink ...   |  S   |  T
> cp -H -l -R  filelink ... |  S   |  T

great

> cp  -l -R  dirlink ...    |  S   |  NDH
> cp  -l -R  danglink ...   |  S   |  ERR_DEREF

These are Ok too I think given that
cp -al will not deref and thus not give the errors.

>   NDH = New directory with hard links below
>   S = hard link to symlink
>   T = hard link to symlink target
>   ERR_DEREF = failure because dereferencing fails
> 
> Now, the dereferencing behavior of cp --link is not related to -R anymore.
> I hope we don't introduce a regression ...
> 
> Comments?

Small suggested adjustment to NEWS:

+  cp --link now dereferences a symbolic link as source before creating the
+  hard link in the destination unless the -P,--no-deref option is specified.
+  Previously, it would create a hard link of the symbolic link, even when
+  the dereferencing options -L or -H were specified.

In the test I would do this to minimise writes to disk:

- cp --help > file       || framework_failure_
+ touch file       || framework_failure_

Very nice test BTW.

thanks!
Pádraig.