https://bugs.winehq.org/show_bug.cgi?id=47787
Bug ID: 47787 Summary: Path maniplation bug in cpython 3.5/3.6 but not 3.7 Product: Wine Version: 4.16 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: zzhang@codeweavers.com Distribution: ---
Bug reported by Sebastian M. Ernst on wine-devel mail list.
Found one more odd thing and it might be closely related (if not the same bug). I tested different versions of CPython for Windows on Wine 4.14 and noticed that pytest (a Python test library) was somehow broken on CPython 3.5 and 3.6 but not on CPython 3.7. It can also be traced back to path manipulation:
# CPython 3.5.4 user@comp:/path/to/target> wine python.exe -c "from pathlib import Path; print(Path('.').resolve())" Traceback (most recent call last): File "<string>", line 1, in <module> File "pathlib.py", line 1109, in resolve File "pathlib.py", line 186, in resolve FileNotFoundError: [WinError 2] Datei nicht gefunden: '.'
# CPython 3.6.3 user@comp:/path/to/target> wine python.exe -c "from pathlib import Path; print(Path('.').resolve())" .
# CPython 3.7.4 user@comp:/path/to/target> wine python.exe -c "from pathlib import Path; print(Path('.').resolve())" Z:\path\to\target
CPython 3.7 is correctly resolving the path '.' while CPython 3.5 and 3.6 fail in different ways. All three examples work correctly on Windows 10. "Datei nicht gefunden" translates to "file not found".
If any one wants to take this bug. Please assign it. Thanks.
https://bugs.winehq.org/show_bug.cgi?id=47787
Sebastian Ernst ernst@pleiszenburg.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ernst@pleiszenburg.de
https://bugs.winehq.org/show_bug.cgi?id=47787
Jeff Smith whydoubt@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |whydoubt@gmail.com
--- Comment #1 from Jeff Smith whydoubt@gmail.com --- I would be happy to assign this to myself, but I don't have the privileges. I I already have some ideas on this, and can look into it more this evening and tomorrow, so feel free to assign me.
https://bugs.winehq.org/show_bug.cgi?id=47787
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|wine-bugs@winehq.org |whydoubt@gmail.com Keywords| |download, source
--- Comment #2 from Austin English austinenglish@gmail.com --- Assigning as requested.
https://bugs.winehq.org/show_bug.cgi?id=47787
--- Comment #3 from Jeff Smith whydoubt@gmail.com --- As a workaround, map the "nearest" mount point to a drive letter.
In CPython, the resolve() method eventually calls os__getfinalpathname_impl in Modules/posixmodule.c. Prior to CPython 3.6.5, one of the calls made from there is GetFinalPathNameByHandle(...,0,0,VOLUME_NAME_NT).
If the path being checked is on a mounted drive NOT mapped to a drive letter in Wine configuration, the GetFinalPathNameByHandle call will fail. For instance, on my machine /home is a mount point. While / is mapped to Z:, /home is not mapped. If I try to check /home/jeff it will fail. Note that cross-volume symbolic links likely trigger this issue as well. Python 3.5 and 3.6 deal with the failure in different ways, but this is where the problem originates.
An actual fix for GetFinalPathNameByHandle does not appear to be a simple task, but I have submitted a patch to emit a fixme message when the situation is encountered. https://source.winehq.org/patches/data/170201