pathlib mistakenly assumes os.getcwd() is a resolved path in Windows

@pfmoore

BPO	43455
Nosy	@pfmoore, @tjguk, @zware, @eryksun, @zooba, @uranusjr
PRs	bpo-38671: Make sure to return an absolute path in pathlib._WindowsFlavour.resolve() #17716

^{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:

assignee = None
closed_at = None
created_at = <Date 2021-03-09.23:05:56.225>
labels = ['type-bug', '3.8', '3.9', '3.10', 'library', 'OS-windows']
title = 'pathlib mistakenly assumes os.getcwd() is a resolved path in Windows'
updated_at = <Date 2022-03-03.10:05:28.651>
user = 'https://github.com/eryksun'

bugs.python.org fields:

activity = <Date 2022-03-03.10:05:28.651>
actor = 'uranusjr'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)', 'Windows']
creation = <Date 2021-03-09.23:05:56.225>
creator = 'eryksun'
dependencies = []
files = []
hgrepos = []
issue_num = 43455
keywords = ['patch']
message_count = 2.0
messages = ['388393', '414415']
nosy_count = 6.0
nosy_names = ['paul.moore', 'tim.golden', 'zach.ware', 'eryksun', 'steve.dower', 'uranusjr']
pr_nums = ['17716']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue43455'
versions = ['Python 3.8', 'Python 3.9', 'Python 3.10']

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).

I believe this has been fixed in #25264

@eryksun

Hey @eryksun, could you check whether this is valid after #25264 was merged? Pathlib now calls ntpath.realpath(), which (from scanning the code) doesn't appear to suffer from this bug.

I never had a practical case for not s, since it's at least ".". Anyway, this is a non-issue now. It was only kept open for 3.8 and 3.9, and the last bugfix for 3.9 was released on 2022-05-17.

Navigation Menu

Repository navigation

pathlib mistakenly assumes os.getcwd() is a resolved path in Windows #87621

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

pathlib mistakenly assumes os.getcwd() is a resolved path in Windows #87621

Description

Activity

eryksun commented on Mar 9, 2021

uranusjr commented on Mar 3, 2022

barneygale commented on Jul 23, 2022

eryksun commented on Jul 24, 2022

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions