did not reply all ---------- Forwarded message ---------- From: Ernesto Alfonso <erjoa...@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 >