bug-coreutils
[Top][All Lists]
Advanced

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

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


From: Paul Eggert
Subject: bug#31335: Fwd: bug#31335: unexpected cp -f behavior
Date: Tue, 15 May 2018 17:11:25 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

On 05/15/2018 10:05 AM, Pádraig Brady wrote:
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.

POSIX is arguably ambiguous about what 'cp -f S D' should do if D is a symlink to itself. POSIX says that if D "exists", then cp must try to unlink and then re-create D; and that if D does not "exist", cp must fail. So, if one considers a self-symlink as "existing", then GNU cp doesn't conform to POSIX; if one considers such a symlink as not "existing", then GNU cp conforms. Unfortunately, as far as I can tell POSIX never exactly defines what "exists" means in this context.

That being said, POSIX uses nearly the same wording for 'ln -f' that it does for 'cp -f', which implies that cp should be consistent with ln, and GNU ln (like most ln implementations) treat self-symlinks as "existing" in this case. Also, other implementations of cp seem act like ln does here, so they interpret the ambiguity in POSIX the opposite way that GNU cp does. Furthermore, I think that users by and large expect the non-GNU interpretation where 'cp -f' is like 'ln -f'. For all these reasons, I'm inclined to think that GNU cp should fall into line here.






reply via email to

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