[Bug 47787] New: Path maniplation bug in cpython 3.5/3.6 but not 3.7
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(a)winehq.org Reporter: zzhang(a)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(a)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(a)comp:/path/to/target> wine python.exe -c "from pathlib import Path; print(Path('.').resolve())" . # CPython 3.7.4 user(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47787 Sebastian Ernst <ernst(a)pleiszenburg.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ernst(a)pleiszenburg.de -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47787 Jeff Smith <whydoubt(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |whydoubt(a)gmail.com --- Comment #1 from Jeff Smith <whydoubt(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47787 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|wine-bugs(a)winehq.org |whydoubt(a)gmail.com Keywords| |download, source --- Comment #2 from Austin English <austinenglish(a)gmail.com> --- Assigning as requested. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47787 --- Comment #3 from Jeff Smith <whydoubt(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla