cp: incorrectly copies directory when path ends in dot

[jfinkels]

cp -R incorrectly copies a directory when the path ends in a dot.

GNU cp v8.30:

mkdir x y
cd y
cp -R ../x/. .  # succeeds and does *not* copy x/ into y/

uutils cp:

mkdir x y
cd y
../target/debug/cp -R ../x/. .  # succeeds and *does* copy x/ into y/

The corresponding GNU test case is tests/cp/src-base-dot.sh. This test is incorrectly marked as passing on the main branch because the GNU test case doesn't actually verify that the directory x/ is not copied to y/.

Originally mentioned by @jfinkels in https://github.com/uutils/coreutils/issues/3894#issuecomment-1236041009

[stefins]

I'm working on this!

Edit: I'm not working on this anymore

[eds-collabora]

I had a quick look into this. The issue is that rust normalizes out of existence most occurrences of '.' in paths whenever API methods are called (i.e. lazily) which interacts incorrectly with the logic that's in place. In particular,

let root_parent = if target.exists() {
    root_path.parent()
} else {
    Some(root_path.as_path())
};

produces the wrong answer in the case of the code in cp. If we take the example, then

cp -R ../x/. .

leads to root_path = <cwd>/y/../x/. and root_path.parent() = <cwd>/y/.. and this is incorrect; the x has been lost from the root path because parent() normalized the trailing dot out of existence before it did anything. This then leads to it being treated as if it were contained in the target, and everything stems from this.

I don't see an easy fix here; it's probably going to come down to a custom implementation running over the OsStr representation of the path I guess.

[jfinkels]

Maybe this is a duplicate of #3886? If so it may be fixed by pull request #3954.

[cakebaker]

Closing this ticket as it seems to be fixed and the directory is not copied when running the example.