cp: Avoid following a destination symlink with -P

[refi64]

Previously, given 'cp -P a b', where 'a' and 'b' were both symlinks, cp
would end up replacing the target of 'b'.

Signed-off-by: Ryan Gonzalez ryan.gonzalez@collabora.com

[refi64]

I think the CI failure is unrelated? Though, in retrospect, maybe a more proper fix would just be to not canonicalize dest if !dereference...

[refi64]

The CI feature is almost definitely unrelated:

---- test_ls::test_ls_long stdout ----
current_directory_resolved: 
touch: /tmp/.tmpFvQ7IK/test-long
run: /target/x86_64-unknown-linux-musl/debug/coreutils ls -l test-long
run: /target/x86_64-unknown-linux-musl/debug/coreutils ls --long test-long
run: /target/x86_64-unknown-linux-musl/debug/coreutils ls --l test-long
run: /target/x86_64-unknown-linux-musl/debug/coreutils ls --format=long test-long
thread 'test_ls::test_ls_long' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 9, kind: Uncategorized, message: "Bad file descriptor" }', library/std/src/process.rs:1862:21


failures:
    test_ls::test_ls_long

but I can't seem to be able to retry it...

Though, in retrospect, maybe a more proper fix would just be to not canonicalize dest if !dereference...

Some testing confirmed that this PR is actually the correct behavior: even if -P is passed to GNU coreutils, the destination is still followed.

[tertsdiepraam]

I thought I fixed that failure :(
I reran the CI for you!

[refi64]

@tertsdiepraam it does look like the previously failing run is passing now!

[refi64]

err, it looks like macOS just hung forever...

[sylvestre]

sorry but we have now a conflict :(
could you please have a look? thanks

[refi64]

@sylvestre conflict should be fixed now!

[sylvestre]

Sweet Changes from main: PASS +1 / FAIL -1 / ERROR +0 / SKIP +0