--- Begin Message ---
|
Subject: |
unexpected cp -f behavior |
|
Date: |
Tue, 01 May 2018 11:14:44 -0700 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) |
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)
What am I missing?
Thanks,
Ernesto
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#31335: Fwd: bug#31335: unexpected cp -f behavior |
|
Date: |
Tue, 15 May 2018 10:05:56 -0700 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
On 03/05/18 23:24, Ernesto Alfonso wrote:
> 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.
Maybe, though that's worth further consideration.
For example rm -f doesn't do everything possible to allow deleting a file.
What if the symlinks where only temporarily dangling due to unmounted dest
for example.
I've pushed at the fix for --remove at:
https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.29-36-ga391007
marking this as done
cheers,
Pádraig.
--- End Message ---