[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#31335: unexpected cp -f behavior

From: Pádraig Brady
Subject: bug#31335: unexpected cp -f behavior
Date: Thu, 3 May 2018 21:30:39 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]