Windows os.path.isabs UNC path bug

[akima]

BPO	22302
Nosy	@pitrou, @serhiy-storchaka, @eryksun, @zooba

^{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 2014-08-29.21:58:22.504>
labels = ['3.10', 'type-bug', 'library', '3.9', 'OS-windows']
title = 'Windows os.path.isabs UNC path bug'
updated_at = <Date 2021-02-25.17:05:14.388>
user = 'https://bugs.python.org/akima'

bugs.python.org fields:

activity = <Date 2021-02-25.17:05:14.388>
actor = 'eryksun'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)', 'Windows']
creation = <Date 2014-08-29.21:58:22.504>
creator = 'akima'
dependencies = []
files = []
hgrepos = []
issue_num = 22302
keywords = []
message_count = 18.0
messages = ['226091', '226108', '226122', '226243', '226427', '226429', '226430', '226432', '226434', '226436', '226440', '226444', '226455', '226473', '226475', '226477', '285510', '387681']
nosy_count = 5.0
nosy_names = ['pitrou', 'serhiy.storchaka', 'eryksun', 'steve.dower', 'akima']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'needs patch'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue22302'
versions = ['Python 3.9', 'Python 3.10']

[akima]

A UNC path pointing to the root of a share is not being recognised as an absolute path when it should be.

See this interpreter session.

PythonWin 3.3.5 (v3.3.5:62cf4e77f785, Mar 9 2014, 10:35:05) [MSC v.1600 64 bit (AMD64)] on win32.
Portions Copyright 1994-2008 Mark Hammond - see 'Help/About PythonWin' for further copyright information.
>>> import os.path
>>> os.path.isabs(r"\\server")
True
>>> os.path.isabs(r"\\server\share")
False
>>> os.path.isabs(r"\\server\share\folder")
True
>>> os.path.isabs(r"\\server\share\folder\folder")
True
>>>

[eryksun]

On second thought, while the parallels between drives and shares are nice, beyond that this makes no sense to me.

http://hg.python.org/cpython/file/c0e311e010fc/Lib/ntpath.py#l91

Windows uses hidden environment variables (e.g. "=C:") for the working directory on each drive, but not for network shares.

[akima]

FYI: I've only tested this bug on Python 3.3.5 on Windows 7. I expect the bug exists in other versions of Python.

[akima]

I checked for the existence of this bug in 2 other python versions today. It's present in CPython 3.4.1, but CPython 2.7.5 doesn't exhibit the issue.

Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os.path
>>> os.path.isabs(r"\\server")
True
>>> os.path.isabs(r"\\server\share")
True
>>> os.path.isabs(r"\\server\share\folder")
True
>>> os.path.isabs(r"\\server\share\folder\folder")
True
>>>


Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 10:38:22) [MSC v.1600 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os.path
>>> os.path.isabs(r"\\server")
True
>>> os.path.isabs(r"\\server\share")
False
>>> os.path.isabs(r"\\server\share\folder")
True
>>> os.path.isabs(r"\\server\share\folder\folder")
True
>>>

[zooba]

Antoine almost certainly thought about this with pathlib and may know about the change, or at least have some decent context on it.

I'm more inclined to think that os.path.isabs(r"\\server") should also return False, since it's not a path that can be opened directly unless you add more path before or after it.

Indeed, pathlib seems to support my understanding:

>>> Path('//server').is_absolute()
False
>>> Path('//server/share').is_absolute()
True
>>> Path('//server/share/').is_absolute()
True
>>> Path('//server/share/file').is_absolute()
True

If the regression appeared in 3.4, it should be easy enough to look at what changed.

[pitrou]

Under Windows, pathlib's "absolute" means a fully qualified path as defined in http://msdn.microsoft.com/en-us/library/aa365247%28v=vs.85%29.aspx

>>> PureWindowsPath("c:").is_absolute()
False
>>> PureWindowsPath("/").is_absolute()
False
>>> PureWindowsPath("c:/").is_absolute()
True

The fact that "//server" isn't considered absolute is a bug in pathlib, since "//server/" is:

>>> PureWindowsPath("//foo").is_absolute()
False
>>> PureWindowsPath("//foo/").is_absolute()
True

I agree that it's not really important, since both aren't actual paths (in the sense that they may not point to anything, AFAIK).

[zooba]

My experience says the main reason people want to know whether the path is absolute is to figure out whether to do Path.cwd() / path or not. According to that MSDN page, they shouldn't because the path starts with "//" (that is, the last character and the existence of the share name are irrelevant here).

Both pathlib and ntpath are reasonably consistent in determining the "drive" of the path:
>>> splitdrive('\\\\server\\')[0]
'\\\\server\\'
>>> splitdrive('\\\\server')[0]
''
>>> Path('\\\\server\\').parts[0]
'\\\\server\\\\'
>>> Path('\\\\server').parts[0]
'\\'

I assume the bug in the last statement is what Antoine is referring to.

The difference in results then comes from how they determine roots.
>>> splitdrive('\\\\server\\')[1]
''
>>> splitdrive('\\\\server')[1]
'\\\\server'
>>> Path('//server/').root
'\\'
>>> Path('//server').root
'\\'

Pathlib always has a root, but splitdrive doesn't.

I'm not sure exactly which one to fix where, but hopefully that helps someone else figure it out.

[zooba]

Just did a double-take, but that output for Path('\\\\server\\').parts[0] is actually correct...

>>> Path('\\\\server\\').parts[0]
'\\\\server\\\\'
>>> print(Path('\\\\server\\').parts[0])
\\server\\

[serhiy-storchaka]

It looks to me that rather handling of "//server/" is buggy than "//server". "//server" is just the same as "/server" or "///server". But "//server/" looks as an UNC path with empty ("") mount point. This is invalid path and we can't create valid path from this path by adding components. Perhaps PureWindowsPath("//server/") should raise an exception.

[eryksun]

Isn't this bug about the "root of a share" case with ntpath.isabs in 3.x and 2.7 (splitdrive was backported)? For example:

 >>> os.path.isabs("//server/share")
 False
 >>> os.path.splitdrive('//server/share') 
 ('//server/share', '')

vs.

 >>> os.path.isabs('//server/share/') 
 True
 >>> os.path.splitdrive('//server/share/')
 ('//server/share', '/')

I think '//server/share' is an absolute path, and pathlib agrees. Network shares do not maintain a current directory the way drives do (i.e. the hidden environment variable trick). There's no such thing as a share-relative path, nor would there be any way to even write such a path, as compared to "C:drive/relative/path".

[pitrou]

Serhiy, you may be right. I'd suggest opening a python-dev discussion to gather more feedback.

[eryksun]

"//server" is just the same as "/server" or "///server".

Repeated slashes aren't collapsed at the start of a Windows path. Here's what I get in Windows 7:

 >>> os.listdir('/server') 
 []
 >>> os.listdir('//server')
 Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 FileNotFoundError: [WinError 53] The network path was not found: '//server'
 >>> os.listdir('///server')
 Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 FileNotFoundError: [WinError 161] The specified path is invalid: '///server'