Automatically convert paths to verbatim for filesystem operations that support it

[ChrisDenton]

This allows using longer paths without the user needing to canonicalize or manually prefix paths. If the path is already verbatim then this has no effect.

Fixes: #32689

[rust-highfive]

r? @m-ou-se

(rust-highfive has picked a reviewer for you, use r? to override)

[ChrisDenton]

I'm not sure which labels I can set but I'll try...

@rustbot label +O-windows +T-libs

[klensy]

This will give additional GetFullPathNameW for some calls, but we can't check perf, until there will be windows machine for perf :-( Hope some day Rust Foundation will find few $ (and time) to build it.

[hkratz]

This will give additional GetFullPathNameW for some calls, but we can't check perf, until there will be windows machine for perf :-( Hope some day Rust Foundation will find few $ (and time) to build it.

That could be easily remedied by using a shortcut for short paths where the whole machinery is not needed.

[ChrisDenton]

This will give additional GetFullPathNameW for some calls, but we can't check perf, until there will be windows machine for perf :-( Hope some day Rust Foundation will find few $ (and time) to build it.

Indeed. However, Windows internally has to do the equivalent to get an NT path from a Win32 path. Admittedly its code is probably better optimized.

That could be easily remedied by using a shortcut for short paths where the whole machinery is not needed.

Yes, this could be done for absolute paths. Though relative paths would still need to made absolute first.

[ChrisDenton]

I've added a shortcut for absolute paths so that they can bypass the GetFullPathNameW call if they are short enough. I also changed the function name because this now means it won't always return a verbatim path.

[hkratz]

I've added a shortcut for absolute paths so that they can bypass the GetFullPathNameW call if they are short enough. I also changed the function name because this now means it won't always return a verbatim path.

I may be missing something obvious here but aren't short relative paths fine as well?

[ChrisDenton]

No, the length of the current directory matters too. Example program:

use std::fs;use std::env;use std::io::Result;fnmain() -> Result<()>{// Set the current directory to some long path that exists and is just short of the 259 limit.let dir = r"Z:\aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\abcdefghi";
env::set_current_dir(dir)?;// This should be successful.let name = "a";println!("Creating `{}`", name);
fs::File::create(name)?;// This should fail.let name = "abc";println!("Creating `{}`", name);
fs::File::create(name)?;Ok(())}

Output:

Creating `a`
Creating `abc`
Error: Os { code: 3, kind: NotFound, message: "The system cannot find the path specified." }

[hkratz]

No, the length of the current directory matters too. Example program: [...]

Ugh, OK. That is worse than I remembered. Thanks for hashing all this out!

[dmitry-zakablukov]

Looking forward for this pr to be merged! It will help us to avoid changing all of our code to support long paths on Windows.
@m-ou-se , @hkratz , is there anything we can do to speed up merging process?

[KapJI]

I tested this on the real project which currently fails on 1.56.0 because of long paths and it works great.
Looking forward to get this merged as well.

[ChrisDenton]

@m-ou-se I think this is again ready for review whenever you have the time (with thanks to KapJI for additional testing and review).

[dtolnay]

@bors r+

[bors]

📌 Commit 37e4c84 has been approved by dtolnay

[rust-timer]

Finished benchmarking commit (2b643e9): comparison url.

Summary: This benchmark run did not return any relevant changes.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

[ChrisDenton]

I think this should be marked as relnotes? It's a pretty big deal for Windows applications because it allows supporting long paths by default and avoids some of the reasons for using canonicalize (which can fail). The latter reason in particular is why I think this could do with a brief mention in the release notes.

@rustbot label +relnotes