cp: error when trying to preserve metadata on dangling symbolic link

[jfinkels]

Combining the -P (--no-dereference) option and the -p (--preserve=mode,ownership,timestamps) option in uutils cp does not match the behavior of GNU cp when attempting to copy a symbolic link that points to a file that does not exist. (Contrast this with issue #3364, which was just about the -P option. That issue was resolved.)

GNU cp:

$ ln -s no-such-file dangle && cp -Pp dangle d2
# no output, d2 is created

uutils cp:

$ ln -s no-such-file dangle && ./target/release/cp -Pp dangle d2
./target/release/cp: 'dangle' -> '/home/jeffrey/src/coreutils/d2': No such file or directory (os error 2)

[jfinkels]

Here's a failing test case:

#[test]
fn test_copy_through_dangling_symlink_no_dereference_permissions() {
    let (at, mut ucmd) = at_and_ucmd!();
    at.symlink_file("no-such-file", "dangle");
    ucmd.args(&["-P", "-p", "dangle", "d2"]).succeeds().no_stderr().no_stdout();
    at.file_exists("d2");

    // `-p` means `--preserve=mode,ownership,timestamps`                                                                                                                                                   
    #[cfg(unix)]
    {
        let metadata1 = at.symlink_metadata("dangle");
        let metadata2 = at.symlink_metadata("d2");
        assert_eq!(metadata1.mode(), metadata2.mode());
        assert_eq!(metadata1.uid(), metadata2.uid());
        assert_eq!(metadata1.atime(), metadata2.atime());
        assert_eq!(metadata1.mtime(), metadata2.mtime());
        assert_eq!(metadata1.ctime(), metadata2.ctime());
    }
}

The error seems to be occurring at this line:

coreutils/src/uu/cp/src/cp.rs

Line 1138 in d921073

fs::set_permissions(dest, source_metadata.permissions()).context(context)?;

(the set_permissions() call returns an Err).

[jfinkels]

I think this may have to do with this: rust-lang/rust#75942:

The documentation for std::fs::set_permissions doesn't say what it does if the given path names a symlink.

Experimentally, it seems that on Unix-family platforms it follows symlinks, while on Windows it does not.

Maybe the call to set_permissions() is attempting to follow the link (named "dangle" in this case) to a file that does not exist (named "no-such-file"), resulting in the "No such file" error. If that is the case, then the solution should be to use a version of set_permissions() that does not follow links.