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
venv fails when called from within long path on Windows #88733
Comments
When trying to create a venv from within a long path name in Windows 10 (long paths enabled in the registry), python crashes. Used python 3.9.6. When reducing the path length by one character, it starts working. btw.: I can see same / similar behavior when using virtualenv/pipenv/poetry (did not try any other venv-like tooling...) For the instructions please check the following snippet: d:\slave\workspace\1--folder-with-232-character-absolute-path-length----------------------------------------------------------------------------------------------------------------------------------------------------------------232>python -m venv .venv %Errorlevel% sometimes was 1 and sometimes was -1073740791 (0xc0000409). Unfortunately I cannot recalled what I had to do to get the latter one... I tried with python 3.8.0, too. Same behavior. |
The secure CRT string functions such as wcscpy_s() and wcscat_s() invoke the invalid parameter handler if the destination string is too small. This defaults to a fastfail that terminates with the status code 0xC0000409, subcode 5 (FAST_FAIL_INVALID_ARG). We're using buffers sized MAXPATHLEN+1 in PC/getpathp.c, which supports 256 characters plus a terminating null. We could increase the buffer size, but bear in mind that Windows itself doesn't completely support running applications from a long path. So you may still hit road blocks. |
I see. Reading https://docs.python.domainunion.de/3/using/windows.html#removing-the-max-path-limitation I thought that the long paths on Win10 are supposed to be supported in general. Is there any blocker in particular which I should keep in mind? |
It enables it for accessing from within Python, but doesn't enable Python itself to be installed into a long path. And because a venv is essentially an installation, they're included in that. (Possibly %PYTHONPATH% entries are too.) I haven't checked how widely MAXPATHLEN is used, but it may be safe enough to just raise it. However, I think that's going to have a memory impact, because the paths used for initialization are kept around for the whole length of the application now. It might be okay though, not sure how many paths are kept. I'm still keen to see the whole getpath implementation replaced with Python code (with suitably injected native helpers), which would make it much easier for us to use dynamically allocated strings of any length. The current implementation is a way off being able to handle this. |
Oh, and there's no harm in adding a note to that doc section explicitly pointing out that it doesn't enable CPython itself to be installed to a long path, and it may not enable packages to be imported from long paths in all scenarios (as it's very feasible that some 3rd party DLLs won't handle long paths). |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: