Eq returns true but hashes are different for some verbatim paths on Windows

[sunshowers]

I tried this code (on Windows):

use std::{
    hash::{BuildHasher, RandomState},
    path::Path,
};

fn main() {
    let path1 = Path::new(r"\\?\C:/foo");
    let path2 = Path::new(r"\\?\C:\foo");

    let hasher = RandomState::new();

    println!("{path1:?} == {path2:?}: {}", path1 == path2);
    println!(
        "hash({path1:?}) == hash({path2:?}): {}",
        hasher.hash_one(path1) == hasher.hash_one(path2)
    );
}

I expected to see this happen:

"\\\\?\\C:/foo" == "\\\\?\\C:\\foo": false
hash("\\\\?\\C:/foo") == hash("\\\\?\\C:\\foo"): false

i.e paths to not be equal, since these are UNC paths that should not be normalized.

Instead, this happened:

"\\\\?\\C:/foo" == "\\\\?\\C:\\foo": true
hash("\\\\?\\C:/foo") == hash("\\\\?\\C:\\foo"): false

This violates the requirement that if two values of a type are equal, their corresponding hashes should be equal.

Meta

rustc --version --verbose:

rustc 1.100.0-nightly (fb6531d55 2026-08-23)
binary: rustc
commit-hash: fb6531d550e0075b9eb9a51464f404805eec87d9
commit-date: 2026-08-23
host: aarch64-pc-windows-msvc
release: 1.100.0-nightly
LLVM version: 23.1.0

[sunshowers]

(This could be fixed either by making the paths unequal or the hashes equal. I think the former is the right fix, though it will be a user-visible change.)

[maxdexh]

Do note that these (\\?\...) are device paths (aka extended-length paths), not UNC paths. A UNC path is a path that starts with two separators not followed by ? or . (MS Docs).

So this is what's happening as far as I understand:

• Path::eq just compares the Path::component iterators
• Path::hash has a weird custom implementation, seemingly as an optimization. If it just hashed the components (or did the reimplementation right), the results here would be at least consistent.

I'm not sure that any of this is appropriate for \\?\ paths though. MS docs explicitly state that \\?\ paths skip normalization. I'm pretty sure they're passed to the device driver as-is, and so \\?\BASE\a\b, \\?\BASE\a\.\b, and \\?\BASE\a/b may all be treated differently by whatever handles paths to BASE (More docs). Making them equal means that e.g. a HashSet/BTreeSet of paths may end up deduplicating incorrectly.

[ChrisDenton]

In Rust nomenclature \\?\ paths are called "verbatim paths". The MS docs call both \\?\ and \\.\ path "device paths" but they are materially different so Rust makes a distinction. A \\?\ path is passed through as-is (hence verbatim) whereas a \\.\ path does undergo some normalization.

So while \\?\C:\foo/bar is technically different from \\?\C:\foo\bar, the same is not true for \\.\C:\foo/bar and \\.\C:\foo\bar.

The mitigation here is that / in filenames is typically not allowed. And if you did manage it then they'd be broken for most other things (i.e. you may have a verbatim path but that doesn't mean other people do). That said, Rust should robustly handle these cases.

[maxdexh]

Yes, which is why I only talked about \\?\ paths, not about device paths in general. I just wanted to clarify that these are not UNC paths.

Now that I look at the code, I think it does actually handle this correctly inside paths by only recognizing \ as a separator. Could it be that it's just skipping the first separator after the drive letter? Prefix::VerbatimDisk only has the drive letter and the components don't contain separators.

[maxdexh]

What even is the slash in \\?\C:/path? If only \ is treated as a separator, then I think this should not be a VerbatimDisk at all, but instead a Verbatim! Since / is just a regular character here.

[ChrisDenton]

I think this should not be a VerbatimDisk at all, but instead a Verbatim

I would agree.

[maxdexh]

Do you want to review the PR?

@rustbot claim