bug#31335: unexpected cp -f behavior

[Pádraig Brady]

On 01/05/18 11:14, Ernesto Alfonso wrote:
> 
> cp -f fails when destination is a recursive symlink:
> 
>     $ ln -s self self
>     $ cat self 
>     self: Too many levels of symbolic links
>     $ touch a
>     $ cp a self 
>     cp: failed to access 'self': Too many levels of symbolic links
>     $ cp -f a self 
>     cp: failed to access 'self': Too many levels of symbolic links
>     
> 
>>From the man page:
> 
>        -f, --force
>               if  an  existing destination file cannot be opened, remove it 
> and try again (this option is ignored when
>               the -n option is also used)

Note cp will still write through symlinks with -f.
For example with dangling symlinks one gets:
  cp: not writing through dangling symlink '...'
I.E. -f currently only removes the symlink if
the destination exists but can't be opened.
This looks to be an explicit decision which I'd be reluctant to change.
I've added a test and some docs to make this apparent.

Now there is also the --remove-destination option
which is a more explicit request to always delete
the destination first. Would that suffice?
Note that doesn't even work currently,
so the attached enables that, so that command line args
are treated similarly to traversed files.

cheers,
Pádraig

cp--remove-symlink.patch
Description: Text Data