Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate better Windows long-path error handling #13141

Open
ehuss opened this issue Dec 8, 2023 · 1 comment
Open

Investigate better Windows long-path error handling #13141

ehuss opened this issue Dec 8, 2023 · 1 comment
Labels
A-diagnostics Area: Error and warning messages generated by Cargo itself. A-filesystem Area: issues with filesystems E-hard Experience: Hard O-windows OS: Windows S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.

Comments

@ehuss
Copy link
Contributor

ehuss commented Dec 8, 2023

#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:

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 prints The 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.

@ehuss ehuss added E-hard Experience: Hard A-diagnostics Area: Error and warning messages generated by Cargo itself. O-windows OS: Windows S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted. A-filesystem Area: issues with filesystems labels Dec 8, 2023
@ChrisDenton
Copy link
Member

ChrisDenton commented Dec 8, 2023

It might be worth investigating embedding a metadata file in build scripts. Though, as you say, the practical effects on long path handling would likely be limited as they're usually either pure rust (which has fairly decent handling of long paths nowadays) or spawn another process (e.g. cc) where the current process' manifest won't make a difference.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Error and warning messages generated by Cargo itself. A-filesystem Area: issues with filesystems E-hard Experience: Hard O-windows OS: Windows S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
Projects
None yet
Development

No branches or pull requests

2 participants