cp: fix symlink-overwrite error-priority

[Luv-Ray]

fix #6266

[github-actions]

GNU testsuite comparison:

Skip an intermittent issue tests/tail/inotify-dir-recreate (fails in this run but passes in the 'main' branch)

[BenWiederhake]

Yes, your change solves a bug, specifically for the scenario you test in test_copy_symlink_overwrite. However, if you try out #6266, which you claim to fix, the error message is unchanged:

target$ rm -f README.md && cp -vs ../README.md ../good/README.md .
'../README.md' -> './README.md'
cp: will not overwrite just-created './README.md' with '../good/README.md'
[$? = 1]
target$ rm -f README.md && cargo run -q cp -vs ../README.md ../good/README.md .
'../README.md' -> './README.md'
cp: will not copy '../good/README.md' through just-created symlink './README.md'
[$? = 1]

[Luv-Ray]

Sorry for missing the test, I think it should be fixed now.

[BenWiederhake]

Looks correct, and I can't find a counter-example. There's no reason against merging this.

However, this feels a bit like enumerating the test cases and just hard-coding the response to each case. Are those really all cases? I'm a bit worried that this turns into a drawn-out game of whack-a-mole.

[Luv-Ray]

I find some other counter-examples after trying:

let a, b and c be three dictionaries, and run cp a/t b/t c

• if a/t and b/t both be dictionaries (also add -r), the copy should success, but it will report an error: will not overwrite just-created 'a/t' with 'b/t'.
• if a/t and b/t both be broken linkes, error should be will not overwrite just-created 'a/t' with 'b/t', but it actually be will not copy 'b/t' through just-created symlink 'a/t' (priority wrong).

I'm not sure whether I should open another issue to report it, I will try to find a more general way to resolve it any way.

[github-actions]

GNU testsuite comparison:

Skip an intermittent issue tests/tail/inotify-dir-recreate (fails in this run but passes in the 'main' branch)
Congrats! The gnu test tests/rm/rm2 is no longer failing!

[BenWiederhake]

Thank you for searching for more edge cases! Sounds like our logic is completely not aligned with what GNU coreutils does.

I will try to find a more general way to resolve it any way.

That sounds like the correct approach here. There should be a reasonably easy way to write this logic.

The brute-force way to do this is to make a kind of "map" al "all" behaviors, kinda like a truth table (or a Karnaugh map if you're fancy), and then squint at it to see patterns, like "Oh this entire region behaves like X, so that's probably the first if, …", and use that to (re-)implement our logic, which may or may not result in something cleaner than we currently have.

Of course, there are other ways.