Description
#13131 added a Windows manifest to make cargo long-path aware, however there is still a long road to actually handling long paths well. The current error messages are not great, and don't really lead the user to understanding what is wrong. It might be helpful to have error messages that are more proactive, and either tell the user how to fix the problem or tell them what is wrong. Recommendations could be:
- setting the
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled
registry entry to 1 - just let them know about the limitation on Windows.
- set the
core.longpaths=true
option in git (though cargo should do this automatically in some cases, see "error: path too long" on Windows when doing "cargo install --git" #13020)
Another consideration is to just add some documentation somewhere to help guide users.
Examples (assuming a build after the manifest was added in #13131):
Registry src path ends up spilling over the limit
If the root path is too long, cargo can't spawn rustc due to the current directory limit.
Caused by:
could not execute process `rustc --crate-name regex_syntax --edition=2021 'C:\....` (never executed)
Caused by:
The directory name is invalid. (os error 267)
Does not matter if the registry entry is set.
Running in the current directory whose path is too long.
I don't think there is anything that cargo can do here, since I don't think any Windows shell supports this, and the errors are strange.
cmd
printsThe current directory is invalid.
- git bash prints
Error: Current working directory has a path longer than allowed for a Win32 working directory. Can't start native Windows application from here.
- Powershell 7.4 prints nothing. There is a window that opens and closes instantly, too fast to see. Nothing else happens.
- Powershell 5.1 prints
cargo.exe failed to run: The directory name is invalid
with a bunch more information.
-C
current directory
Without the registry entry set:
error: could not change to requested directory
Caused by:
The filename or extension is too long. (os error 206)
With the registry entry set (which unfortunately makes the error worse):
error: could not execute process `rustc -vV` (never executed)
Caused by:
The parameter is incorrect. (os error 87)
Cloning git dependency or index with a path that is too long
See #13020, which might be fixable. If core.longpaths
is not set, you get this error:
error: path too long: 'C:/...'; class=Filesystem (30)
Building with a target directory where the paths end up exceeding the limit
link.exe
can fail with various errors like:
error: linking with `link.exe` failed: exit code: 1104
|
= note: "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools\\VC\\Tools\\MSVC\\14.29.30133\\bin\\HostX64\\x64\\link.exe" ...
= note: LINK : fatal error LNK1104: cannot open file 'C:\...\foo.exe'
Does not matter if the registry entry was set. This is Visual Studio 2019, newer versions might be better. Needs more investigation.
Build scripts struggle with paths that are too long
Because build scripts themselves are not built with a windows manifest, they are not long-path-aware. Thus, if they try to do certain things with files in the target directory (like OUT_DIR) or reading files from within the package directory, they may run into various errors depending on what they are doing. Additionally, they may be forking out to external processes (like from the cc
crate) which are further out of our control. Fortunately Rust path handling has improved somewhat recently to make this less likely.
Others?
I'm sure there are a bunch of other examples. Pretty much anything that touches the filesystem or spawns processes or deals with paths, which is almost the entirety of cargo.
Notes
See meta tracking issue #9770.