Path::components().as_path() for "///a/b" failing to normalize multiple slashes for root dir on Unix

[programmerjake]

I'd expect the path to be normalized to "/a/b" since that is a substring of "///a/b".

On some Unix implementations a leading // is special, but the Unix and POSIX specs state that a leading /// is equivalent to just one /. On Linux, // is also the same as /, though it has been proposed for that to change.
Stack Exchange: On what systems is //foo/bar different from /foo/bar?

use std::path::Path;

fn main() {
    let expected = "/a/b";
    let actual = Path::new("///a/b").components().as_path().to_str().unwrap();
    assert_eq!(expected, actual);
}

(Playground)

Errors:

   Compiling playground v0.0.1 (/playground)
    Finished release [optimized] target(s) in 3.78s
     Running `target/release/playground`
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `"/a/b"`,
 right: `"///a/b"`', src/main.rs:6:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[the8472]

components()

When parsing the path, there is a small amount of normalization

.as_path()

Extracts a slice corresponding to the portion of the path remaining for iteration.

Since slices are contiguous they cannot be the result of parsing and thus don't include normalization. Plus only the iterated parts will have been parsed, as_path returns the unparsed remainder.

[programmerjake]

@the8472

Since slices are contiguous they cannot be the result of parsing and thus don't include normalization.

That's not correct, normalization can be done as long as the result is either a substring of the input or a static string.

For example, "a/./b/./." is normalized to "a/./b" since components() can just reduce the length to removing the trailing "/./.":
https://play.rust-lang.org/?version=nightly&mode=release&edition=2018&gist=0730bdbe3f6dc1dc17b46b7bd8c5bfdb

[the8472]

Sure, but in the general case it cannot guarantee normalization, therefore the question is where does the expectation come from? It's not part of the API.

[programmerjake]

The docs for Path::components state that:

Repeated separators are ignored, so a/b and a//b both have a and b as components.

I'd argue that all but the first slash in ///a//b/. (switching to a better example) are separators, so the Path should be normalized such that only the necessary separators show up: /a//b -- the initial slash is needed to denote the root dir, and the slashes between a and b are necessary to avoid allocating. All other slashes are trimmed from the underlying OsStr -- normalization to a substring.

[programmerjake]

alternatively, if separator is interpreted to mean the / character specifically (on Unix; a specific character as opposed to a thing that separates), then that makes an even better argument for normalizing ///a//b/. to /a//b

[the8472]

My argument is that the normalization described in Path::component logically cannot be part of the Components::as_path contract because separators in the middle cannot be normalized if the returned value is a slice. Therefore we can only rely on what as_path itself promises, which doesn't mention any normalization.

[programmerjake]

I think everyone can agree that .components().collect() does a full normalization (to the extent specified by components's docs). The issue here is that .components().as_path() does less normalization than expected even when considering the constraints of not allocating.

[eggyal]

Apologies, clearly I'd missed the point here!!

[programmerjake]

Maybe you're really looking to canonicalize instead?

nope, I'm writing a reimplementation of Path for use in a virtualized/sandboxed Linux filesystem (even if the host OS isn't Unix), I definitely don't want it to access the host's filesystem.

[programmerjake]

Apologies, clearly I'd missed the point here!!

no problem! If I weren't writing a virtual filesystem, canonicalize or components().collect() would definitely be useful!

[the8472]

The issue here is that .components().as_path() does less normalization than expected even when considering the constraints of not allocating.

What I am trying to say is that one shouldn't expect anything from it since the components() contract is clearly not applicable. as_path() itself on the other hand only promises to return the tail of whatever remains in the iterator. And since iterators are lazy (per core::iter module documentation) one can't expect it to do any work to do additional parsing or normalization.

So the default expectation should be to just get a slice of whatever remains in the iterator (as the documentation says), which may contain some non-normalized path elements. That it currently happens to strip things off the tail is something going beyond its contract, but that shouldn't inform further expectations, on the opposite, one should code defensively because this current behavior is not guaranteed and could thus go away at any point in the future.

Imo there's no failure here, the methods are within specification.

[eggyal]

Imo there's no failure here, the methods are within specification.

So feature request then?

@rustbot label: +T-libs +C-feature-request