This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: pathlib mistakenly assumes os.getcwd() is a resolved path in Windows
Type: behavior Stage: patch review
Components: Library (Lib), Windows Versions: Python 3.10, Python 3.9, Python 3.8
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: eryksun, paul.moore, steve.dower, tim.golden, uranusjr, zach.ware
Priority: normal Keywords: patch

Created on 2021-03-09 23:05 by eryksun, last changed 2022-04-11 14:59 by admin.

Pull Requests
URL Status Linked Edit
PR 17716 uranusjr, 2021-03-09 23:07
Messages (2)
msg388393 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2021-03-09 23:05
pathlib._WindowsFlavour.resolve() mistakenly assume that os.getcwd() returns a resolved path in Windows:

    s = str(path)
    if not s:
        return os.getcwd()

I don't think this is a practical problem since `str(path)` should never be an empty string. But if there is a concern that the result is an empty string, the code should use `s = str(path) or '.'`, and resolve "." like any other relative path.

In POSIX the result of getcwd() "shall contain no components that are dot or dot-dot, or are symbolic links". In Windows, os.getcwd() calls WinAPI GetCurrentDirectoryW(), which returns a fully-qualified path that may contain symbolic components that would be resolved in a final path. This includes filesystem symlinks and bind mounts (junctions), as well as mapped and substitute drives (i.e. drives that resolve to a filesystem directory instead of a volume device).
msg414415 - (view) Author: Tzu-ping Chung (uranusjr) * Date: 2022-03-03 10:05
I believe this has been fixed in
Date User Action Args
2022-04-11 14:59:42adminsetgithub: 87621
2022-03-03 10:05:28uranusjrsetmessages: + msg414415
2021-03-09 23:07:12uranusjrsetkeywords: + patch
nosy: + uranusjr

pull_requests: + pull_request23574
stage: patch review
2021-03-09 23:05:56eryksuncreate