std::path::Path prefix parsing in Windows is inconsistent with other OS's

[ncihnegn]

I tried this code:

Path("//tmp/abs_evil2.txt").components()

I expected to see this happen:

RootDir, RootDir, Normal("tmp"), Normal("abs_evil2.txt")

Instead, this happened:

Prefix(PrefixComponent { raw: "//tmp/abs_evil2.txt", parsed: UNC("tmp", "abs_evil2.txt") })

[ChrisDenton]

This is intentional. Path is an abstraction over the paths of the platform it's used on. On Unix this is a POSIX path and on Windows it's a Win32 path. So they are not expected to work the same across platform.

In this case the path //tmp/abs_evil2.txt is parsed as a Win32 UNC path on Windows. Note also that Windows normalizes / to \ so //tmp/abs_evil2.txt is equivalent to \\tmp\abs_evil2.txt.

[ChrisDenton]

@rustbot label +O-windows +A-io

[ncihnegn]

I think it is incorrect to parse a POSIX path into a Win32 path.

A path should be parsed as UNC only if it starts with \\, not when it starts with //.

[Kobata]

There is no difference, as pointed out above Windows will accept either / or \ mostly-equivalently[1].

It's fairly easy to see, for instance in cmd running something like dir "//./C:/" (you do need the quotes for it to think it's a path) is equivalent to dir \\.\C:\ (which is also equivalent to dir "C:/" and dir C:\)

[1] The exception is paths that begin with exactly \\?\, using backslashes, //?/ is also a valid path-prefix but doesn't have the special handling that the backspace-version does.

[ncihnegn]

Is there any way to force POSIX path parsing or disable UNC parsing?

[ChrisDenton]

Disabling UNC parsing wouldn't make sense, even if it were possible it's still a Windows path so / wouldn't be a RootDir. What you're looking for is UnixPath which doesn't yet exist in std. Currently you'd have to use a third party crate (or make your own).

[chipsenkbeil]

@ncihnegn @ChrisDenton I just published typed-path as a means to partially solve this problem by providing UnixPath and WindowsPath, in case you were interested in something like this.

[ChrisDenton]

Great! I'm closing this issue in favour of #66621 or using a crate.