Don't Canonicalize Paths

[Alexhuszagh]

Path canonicalization is generally a good idea for security reasons, and we should do it for the uniqueness of our hashes, but it can affects crates that wish to mount volumes that are symlinked and get data specifically using relative paths or absolute paths to the volume, which can differ from the canonical path.

Say my crate does something like:

main.rs

pub fn main() {
    println!("{}", std::fs::read_to_string(std::path::Path::new("/tmp/config.toml")).unwrap());
}

Now, /tmp/config.toml is on macOS, which is actually mounted at /private/tmp/config.toml, so canonicalizing the path will mean /tmp is not mounted, but /private/tmp is. So in this case, we have a path where the parent directory is a symlink and this code will now fail.

[Emilgardis]

I'm not sure I follow the bug description. How is this a bug in cross?

[Emilgardis]

The issue is that symlinks through canonicalization can destroy assumptions about paths.

Ideally, we'd have to tell the users of cross to always use the env var for mounts, but realistically this breaks on assumptions like the shown example for macOS