Open richkadel opened 3 years ago
Possible solutions are listed in https://github.com/rust-lang/rust/issues/76586#issuecomment-691949376
Long paths feature is enabled on Github Actions so if Rust added special manifest to it's binaries CI would not hit this issue. However this feature is not enabled by the default on any Windows so developers can still hit this issue unless they have explicitly enabled this feature.
As a not ideal workaround for this specific case you could convert the path to the normalised format (it starts with \\?\
) by running canonicalize()
right before writing to that path. "Right before writing to that path" is important here because normalised paths are always absolute and don't support pushing ..
(one dir up) so they are often horrible to work with.
cc https://github.com/rust-lang/rust/issues/67403 https://github.com/rust-lang/rust/issues/76586
Thanks @mati865 ! I saw that first issue you referenced. Glad you linked the possible solutions comment here.
A general solution for Rust would be most welcome.
I was just thinking that, in the mean time, we might be able to add a simple check somewhere, like in compiletest
, to save some future poor soul from the kind of trouble I ran into... haha.
Agree the canonicalize() is not great. I worked around the problem already though.
Thank you!
Hopefully this has been fixed by #89174.
The problem and a proposed guard to avoid wasting time and resources
This bug (panic message shown below) resulted from a combination of components with long names, resulting in mir-dump output that tried to create a file path exceeding Windows' 260 byte (give or take?) max path length limit.
The
bors
CI builds for Windows, under both MSVC and mingw/gnu are susceptible to this kind of failure.I worked around the problem by abbreviating directory names, rust program file names, and symbols inside the rust program, all of which contributed to the long path name.
The error messages produced by Rust and/or Windows (
NotFound
) offer no obvious clue that the problem is the path length. (Thankfully I knew enough to suspect it, but others may not.)This was not caught until I ran the tests under CI, and it happened more than once (at least once under MSVC, which I fixed, and then again under mingw, because I didn't shrink the paths enough the first time.
This is something that could be caught early, during development (even before sending to bors).
My recommendation is, when
compiletest
runs a test on any platform (e.g., Linux or MacOS, where this problem does not crop up naturally because they don't have path limits),compiletest
should check the lengths of all generated files in thebuild/<target>/src/test
directory. Strip the directory prefix up throughbuild
, and if the remaining subpath of any file path is greater than, say, 215 characters, generate an error or warning (something the developer won't miss) that their test is generating paths that may exceed path limits on Windows, and may not pass CI.This should be enough to get the developer to update their tests and avoid the entire problem.
Meta
Error output
(Newlines inserted for readability.)