std::path::posix::Path should not automatically normalize

[alanfalloon]

Because of symlinks, on POSIX systems, in general you can't claim that foo/bar/../baz is the same path as foo/baz. If foo/bar is a symlink with target flip/flop then the abspath of foo/bar/../baz is actually foo/flip/baz. Normalizing the path symbolically changes the meaning of the path. (reducing // to / is still valid though)

Other issues like #11650 are symptoms of this issue, execvp is not the only call that changes behaviour when path components are stripped out.

The std::path::posix::Path module needs to leave the paths un-normalized internally, and re-introduce an explicit normpath method (distinct from os::make_absolute for the reasons outlined above).

[huonw]

cc @kballard

[lilyball]

Crap. You're right. Although I think automatically normalizing ./foo to foo is still valid, the only invalid operation is automatically interpreting .. segments. This means that #11650 is still valid for Process::new(), because it does need to treat ./foo and foo differently, although the dynamic_library::open_external part will work correctly with Paths if this is fixed.

This is unfortunate, because automatically normalizing paths made a lot of things work better in the path library. But I think we can leave the current implementation in place as long as we're ok with e.g. .filename() returning .. (which seems like reasonable behavior).

I guess this means the path library will partially-normalize on Path creation, making safe changes like squashing // to / and removing . components (e.g. everything it does now except for handling of .. components), and it will expose a .normalize() method that handles .. components.

[alanfalloon]

Sounds right to me.

I can't think of a time when normalizing ./ components will bite you (except in cases like execvp where having any directory component at all has a different meaning than a single name). I suppose technically, the . entry could point to a different inode than the current directory, but I think we could reasonably consider that filesystem to be broken.

[alanfalloon]

As a side-note, I made a comment on #13721 about testing being harder due to lack of Show impl.

I agree with the rationale for closing #13009, but if there is some way we can have a Show impl that is on with #[cfg(test)] we will then be able to use assert_eq! and friends in our testing, which would be a big help. I'm not sure if you can bubble up config options like test to external crates, so that might not be possible, but perhaps we can come up with something.

[lilyball]

There's no way for libstd to vend a Show impl that's only with with #[cfg(test)]. Configurations don't work that way.

As I just suggested in #13721, you can still use assert_eq!() if you map your path to a byte vector (&[u8] or Vec<u8> depending on lifetime requirements).