https://bugs.winehq.org/show_bug.cgi?id=45810
Bug ID: 45810 Summary: WINEPATH maximums Product: Wine Version: 3.0.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: paleozogt@gmail.com Distribution: ---
Created attachment 62272 --> https://bugs.winehq.org/attachment.cgi?id=62272 winepath-test.sh
WINEPATH seems to have some undocumented limits, which cause the in-windows PATH to be corrupted.
One limit, around 969 characters, causes the PATH to drop the suffix that's usually appended (C:\windows\system32;C:\windows;C:\windows\system32\wbem).
Another limit, around 1025 characters, causes the PATH to entirely ignore what's in WINEPATH.
I'm not sure why these limits exist-- can't Windows support arbitrarily long PATHs? (I've routinely seen huge PATHs on Win7/Win10.)
The attached winepath-test.sh makes a WINEPATH of various sizes and then echos the size and the %PATH% in the cmd shell.
The output looks like:
$ ./winepath-test.sh
968 C:\aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa;C:\windows\system32;C:\windows;C:\windows\system32\wb
969 C:\aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
1024 C:\aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
1025 C:\windows\system32;C:\windows;C:\windows\system32\wbem
https://bugs.winehq.org/show_bug.cgi?id=45810
Aaron Simmons paleozogt@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |paleozogt@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=45810
Aaron Simmons paleozogt@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |cmd
https://bugs.winehq.org/show_bug.cgi?id=45810
Jason Edmeades us@edmeades.me.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |us@edmeades.me.uk Status|UNCONFIRMED |NEW Ever confirmed|0 |1
--- Comment #1 from Jason Edmeades us@edmeades.me.uk --- Hi Aaron - I guess my first question is what does this break? Basically, can you give me a justification of why we should fix this other than it being something you stumbled upon. If there's a valid application requiring it, we can sort it...
Note that setx etc is limited to 1024 characters apparently (https://superuser.com/questions/387619/overcoming-the-1024-character-limit-w...) and so going over 1024 characters will start to break some scripts on windows anyway.
The problem is easily worked around - there's a 1024 limit in "set_registry_variables" (dlls\kernel32\process.c) and if you change both the 1024 to 2048 for example, then the issue you are seeing goes away.
However the comment for that function says that window happily truncates environment variables in the registry to 1024, but you could argue nothing sensible would ever rely on such truncation.
Some interesting reading at: https://software.intel.com/en-us/articles/limitation-to-the-length-of-the-sy... Sounds like 2048 is a more sensible limit as things start breaking there, and it is unlikely that people expect the broken behaviour of truncation anyway.
(Also referencing https://support.microsoft.com/en-gb/help/830473/command-prompt-cmd-exe-comma... for the future)
https://bugs.winehq.org/show_bug.cgi?id=45810
--- Comment #2 from Aaron Simmons paleozogt@gmail.com --- This isn't just academic. I'm working on some tooling for using MSVC in Wine, along with other dev tools like Java/Python: https://github.com/paleozogt/MSVCDocker
The MSVC development environment puts quite a few things onto the PATH, which runs right up to the limit. Once I add other tools to it, it triggers this bug. I've had to put in a deliberate workaround for the problem here: https://github.com/paleozogt/MSVCDocker/blob/master/dockertools/vcwine#L15 otherwise it will fall down when the WINEPATH is too long and is ignored. The workaround is to just truncate the WINEPATH, but that of course breaks anything unfortunate enough to be past the limit.
btw, you mentioned setx, I don't see setx in Wine:
setx
Can't recognize 'setx' as an internal or external command, or batch script.
Is setx supposed to be there?
https://bugs.winehq.org/show_bug.cgi?id=45810
Jason Edmeades us@edmeades.me.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|wine-bugs@winehq.org |us@edmeades.me.uk
--- Comment #3 from Jason Edmeades us@edmeades.me.uk --- Ok, I'll have a play and see if I can see what this auto truncation comment actually means but aim to up it to 2048 - would such a solution be enough?
Re: setx... no (well, not until anyone needs it I guess), but I more meant that once you go over 1024 (the current limit) things start to break in windows as well such as setx hence it cannot be relied upon too much in practice.
https://bugs.winehq.org/show_bug.cgi?id=45810
--- Comment #4 from Aaron Simmons paleozogt@gmail.com --- Thanks for looking into it. :)
I"m a bit confused by the 1024 limit... I guess its there to emulate some limit that's thought to be in Windows? While setx (and other APIs?) maybe have a 1024 limit, the PATH env var itself doesn't seem to have that limit.
For example, on my Windows 10 dev system, I have a PATH that's 1574 characters:
C:\Users\vagrant>echo %PATH% C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow;C:\Program Files (x86)\MSBuild\12.0\bin;C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE;C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\x86_amd64;C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN;C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools;C:\Windows\Microsoft.NET\Framework\v4.0.30319;C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\VCPackages;C:\Program Files (x86)\Microsoft Visual Studio 12.0\Team Tools\Performance Tools;C:\Program Files (x86)\Windows Kits\8.1\bin\x86;C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\x64;C:\Python27;C:\Python27\Scripts;C:\Python37\Scripts;C:\Python37;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\ProgramData\chocolatey\bin;C:\Program Files\Microsoft SQL Server\110\Tools\Binn;C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0;C:\Program Files\Microsoft SQL Server\120\Tools\Binn;C:\Users\vagrant\AppData\Local\Microsoft\WindowsApps;C:\Program Files (x86)\GnuWin32\bin;;C:\Program Files\Notepad++;C:\Program Files\Git\bin;C:\Program Files\Git LFS;C:\swigwin-3.0.11;C:\Program Files\CMake\bin;C:\Program Files\Java\jdk1.8.0_181\bin;C:\Program Files\doxygen\bin;C:\Users\vagrant\AppData\Local\Pandoc;C:\Program Files (x86)\Graphviz2.38\bin;C:\Program Files\MiKTeX 2.9\miktex\bin\x64;C:\Users\vagrant\AppData\Local\Microsoft\WindowsApps;C:\Users\vagrant\AppData\Local\Pandoc\
Which, as you pointed out, causes grief with setx:
C:\Users\vagrant>setx PATH "%PATH%;C:\foobar"
WARNING: The data being saved is truncated to 1024 characters.
SUCCESS: Specified value was saved.
But that inability for some older parts of Windows to work with long PATHs seems to be expected behavior (!).
https://bugs.winehq.org/show_bug.cgi?id=45810
--- Comment #5 from Aaron Simmons paleozogt@gmail.com --- As for the new max of 2048, here's some max path/env var info that I found:
https://software.intel.com/en-us/articles/limitation-to-the-length-of-the-sy... https://blogs.msdn.microsoft.com/oldnewthing/20100203-00/?p=15083
It seems like the answer is sort of complicated. Sometimes its 2047, sometimes its larger. (And of course it depends on the tool/api in use.) At any rate, 2048 would work for my use-case.
https://bugs.winehq.org/show_bug.cgi?id=45810
--- Comment #6 from Jason Edmeades us@edmeades.me.uk --- Yeah its odd... I'm proposing a patch which takes it up to 2048 (which the intel article indicates is the part at where the o/s behaves oddly). Windows 10 certainly allows longer values in the env vars via the registry (setx is self limiting as per some of the articles), and the truncation doesnt feel like behaviour that any app can be relying on anyway.
I've added it to my local patches and will submit within a week or so (I have others I'm working on), and see whether it gets in or gets shot down :-)
Interesting project too btw :-)
https://bugs.winehq.org/show_bug.cgi?id=45810
--- Comment #7 from Jason Edmeades us@edmeades.me.uk --- https://www.winehq.org/pipermail/wine-devel/2018-September/132655.html
https://bugs.winehq.org/show_bug.cgi?id=45810
--- Comment #8 from Aaron Simmons paleozogt@gmail.com --- Was the patch accepted?
https://bugs.winehq.org/show_bug.cgi?id=45810
--- Comment #9 from Gijs Vermeulen gijsvrm@gmail.com --- Created attachment 69652 --> https://bugs.winehq.org/attachment.cgi?id=69652 script output with wine-6.4
It seems this bug is fixed with wine-6.4.
I think https://source.winehq.org/git/wine.git/commit/e63b8ead4306a72064e47f9c77d4e0a98603f3ae is the commit that fixed it, but I'm not sure.
Please retest and resolve the bug if you can confirm it is fixed.
https://bugs.winehq.org/show_bug.cgi?id=45810
Vijay Kamuju infyquest@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |infyquest@gmail.com Resolution|--- |FIXED Status|NEW |RESOLVED
--- Comment #10 from Vijay Kamuju infyquest@gmail.com --- Marking it as closed as it was fixed long back and no issues during retest
https://bugs.winehq.org/show_bug.cgi?id=45810
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #11 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 9.13.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla