bug#31335: Fwd: bug#31335: unexpected cp -f behavior

[Ernesto Alfonso]

did not reply all

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


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 <address@hidden> 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
>