-
Notifications
You must be signed in to change notification settings - Fork 701
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
cabal run fails on windows due to the long path issue #8841
Comments
Note that @hasufell considers this a blocker to making cabal-install 3.10.1.0 a recommended release |
Thanks for the report, to delimite the scope of the bug:
|
Very interesting and useful, thank you, @jneira ! For the future: am I understanding correctly that it's impossible to test in our test suite because we have CABAL_DIR set. |
To be precise the fact which causes the bug is to set CABAL_DIR to a enough long path. It turns out that the default one is long enough to do it. So setting CABAL_DIR to a long enough path should reproduce the bug. It could be done globally or specifically for a dedicated test |
Maybe page in @bacchanalia in that case |
Just to check, is this reproducible with all GHC releases, or just GHC 9.4? I ask since LLVM 14 (the version of LLVM that ships with GHC 9.4 on Windows) suffers from a long-path–related issue on Windows. I believe older GHCs (which ship with GCC rather than LLVM) are unaffected, and GHC 9.6.1 ships with LLVM 15, which has fixed the aforementioned issue. |
Could somebody please verify if this affects only GHC 9.4.4 or any other GHC as well? @bgamari: I wonder if there's a possibility that GHC 9.4.5 fixes the long path issue on Windows (see the previous comment)?. @bacchanalia: given your recollection of the code of this feature, is there any way to work around the problem? Make a temporary short link just before executing the script? Shorten or eliminate the hash? Remove all the "cabal-script" prefixes to fake package names? |
Good news: the GHC fix is on the horizon: https://gitlab.haskell.org/ghc/ghc/-/issues/21293 [Edit: actually, that's the same ticket @RyanGlScott has linked to, but now it has one more user group advocating for it's backport to 9.4.5 and Ben has kindly written this down in the ticket and made sure it's marked for backport.] Still, long paths have been plaguing the ecosystem for long, for various reasons, so if we can make cabal less fragile with respect to this issue, that would be worthwhile IMHO. |
@bacchanalia: I'm not sure if the notifications are reaching you, so I may try the email. I'd prefer to avoid mucking around with somebody's design and code without as much as informing the author. |
@bacchanalia: I think you started working on this recently, but I can't find the PR. Could you point me to it? Thank you. |
I'm sorry, my life has been really hectic the past week. I didn't realize this was a blocker, sorry. Looking into this now. |
This saves 21 chars in the build path, which should help avoid long path issues on Windows. Bug haskell#8841
@Mikolaj I put a quick fix up which saves 21 chars by using a more compact encoding for the hash. If this isn't enough, I can investigate other methods, like you were discussing in your previous comment. I don't have a Windows development environment set up to test it right now, but should be able to set one up in the next few days. |
Well done! Apologies for badgering --- this is not a clear blocker, but still every saved character is one less potential fresh user struggling, before GHC fixes this upstream. Could a kind Windows user test if this suffices in any standard Windows install? Alternatively, could somebody tweak our CI not to shorten the path by setting CABAL_DIR to something unnaturally short? |
Using a Base64 hash and truncating it to 26 characters, saves 38 chars, which helps avoid long paths issues on Windows, while still providing 130 bits of hash in order to avoid collisions. Bug haskell#8841
Using a Base64 hash and truncating it to 26 characters, saves 38 chars, which helps avoid long paths issues on Windows, while still providing 130 bits of hash in order to avoid collisions. Bug haskell#8841
Using a Base64 hash and truncating it to 26 characters, saves 38 chars, which helps avoid long paths issues on Windows, while still providing 130 bits of hash in order to avoid collisions. Bug haskell#8841
Using a Base64 hash and truncating it to 26 characters, saves 38 chars, which helps avoid long paths issues on Windows, while still providing 130 bits of hash in order to avoid collisions. Bug haskell#8841
* Use shorter hash for script-builds directories Using a Base64 hash and truncating it to 26 characters, saves 38 chars, which helps avoid long paths issues on Windows, while still providing 130 bits of hash in order to avoid collisions. Bug #8841 * Use the script cache dir as the dist dir Putting script build products under dist-newstyle within the cache directory is unnecessary because we already control the cache directory and can ensure there are no conflicts. * Use the actual script name in the executable name Previously, the script name was sanitized in final executable name, because the executable name had to match the component name, which only allowed for a limited character set. Now we can use the actual script name in the executable name. This only lets us shorten the component name without losing clarity. * Add changelog entry * Reenable script tests for Windows/ghc-9.4.*
* Use shorter hash for script-builds directories Using a Base64 hash and truncating it to 26 characters, saves 38 chars, which helps avoid long paths issues on Windows, while still providing 130 bits of hash in order to avoid collisions. Bug #8841 * Use the script cache dir as the dist dir Putting script build products under dist-newstyle within the cache directory is unnecessary because we already control the cache directory and can ensure there are no conflicts. * Use the actual script name in the executable name Previously, the script name was sanitized in final executable name, because the executable name had to match the component name, which only allowed for a limited character set. Now we can use the actual script name in the executable name. This only lets us shorten the component name without losing clarity. * Add changelog entry * Reenable script tests for Windows/ghc-9.4.* (cherry picked from commit a482a63) # Conflicts: # cabal-install/src/Distribution/Client/CmdRun.hs # cabal-install/src/Distribution/Client/ProjectConfig.hs
hi, only want to note that to be precise the issue is not totally fixed, still is possible to hit the limit with enough long script file names as it is noted in the QA notes of the original pr |
Right, but that's not a regression to 3.6, so to speak. Right? |
@jneira cabal can't fix this issue for real, can it? It's limitation of Windows, and we can only try to not hit it too often. |
It could, by using |
or fixing the script file name (losing the complete file name in exchange) |
I backported (#8970) the fix to 3.10 and as the original reporter I feel confident that we can close the ticket because it was specifically describing the regression in 3.8 w.r.t 3.6 that is fixed now (on master and on 3.10 branch). |
Ideas on how to improve our UX on Windows are welcome as separate tickets. |
well the maximum long script file name (it does not depend on full path only the name) is around 30 chars so I I think it will be not reached frequently |
Describe the bug
Copied from IRC:
To Reproduce
No idea.
System information
cabal
,ghc
versions: 3.10.1.0, 9.4.4The text was updated successfully, but these errors were encountered: