did not reply all

---------- Forwarded message ----------
From: Ernesto Alfonso <erjoalgo@gmail.com>
Date: Thu, May 3, 2018 at 11:10 PM
Subject: Re: bug#31335: unexpected cp -f behavior
To: Pádraig Brady <P@draigbrady.com>


To be honest, I think cp -f should behave consistently with rm -f.

    $ ln -s self self
    $ rm -f self 
    $ echo $?
    0

It's also what I would expect, if I use -f, I expect cp will do everything it can to force the operation and succeed if all possible.

Reading the man page, --remove-destination and --force seem to just swap the cp, rm operation, i.e.

--force:                     "cp; if fail, rm; cp"
--remove-destination: "rm; cp"

In either case it seems that the "rm" part should correctly handle a recursive symlink.

This is my opinion as a user of cp and I'm not familiar with the implementation or design decisions.

Thanks,

Ernesto



On Thu, May 3, 2018 at 9:30 PM, Pádraig Brady <P@draigbrady.com> wrote:
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