Windows os.path.isabs UNC path bug #66498

akima · 2014-08-29T21:58:23Z

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 · 2014-08-29T21:58:22Z

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 · 2014-08-29T23:52:12Z

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 · 2014-08-30T06:39:50Z

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 · 2014-09-01T21:18:11Z

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 · 2014-09-05T16:32:59Z

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 · 2014-09-05T16:52:14Z

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 · 2014-09-05T17:16:57Z

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 · 2014-09-05T17:18:25Z

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 · 2014-09-05T17:30:24Z

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 · 2014-09-05T18:06:25Z

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 · 2014-09-05T18:47:31Z

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

eryksun · 2014-09-05T19:09:11Z

"//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'

akima · 2014-09-05T20:50:53Z

As eryksun pointed out, I created this bug report to report on one issue; that \\server\share isn't being consider absolute by os.path.isabs when it should be considered absolute.

I found this bug when I was writing a basic config file parsing module. One of the options in the config (named log_dir) required an absolute path to a directory where my program could dump log files. It has to be absolute because the working directory of the program changes. A user entered a path \\pollux\logs as the log_dir value in their config file and my program rejected it informing the user that it wasn't absolute (because I checked the path using isabs). I've worked around this bug in my program, but it is clearly a problem that needs fixing.

Steve: with regard to what isabs should return when given the string r"\\server": does it really matter whether it returns True or False? As you said; \\server isn't a real path. It's invalid. If you ask python if it's absolute (using os.path.isabs) and you expect a boolean response, no matter whether the response is True or False, the response will be meaningless. Consider this:

Python 3.2.3 (default, Feb 27 2014, 21:31:18) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os.path
>>> os.path.isabs("&monkeyfart!££")
False
>>>

I just asked isabs if "&monkeyfart!££" was absolute and it told me it's not an absolute path, it's relative! It's infact, not even a path. There is no "os.path.isrelative" function. If we want to know if a path is relative we use the isabs function and decide the path is relative if the result is False. If you give the function a junk-string which isn't even a path (eg \\server or &monkeyfart!££ ) then you can only expect a junk response. If we decide that all invalid paths provide to isabs should return False then what we are saying is all invalid paths provided to isabs should be considered relative paths. What use is that to anyone? Really, the programmer should ensure that the path is valid before trying to find out if it's relative or absolute.

To summarize: I think it's important that isabs works correctly when given a *valid* path (like \\server\share). When it's given a string which is an invalid path (like \\server), its behaviour should be undefined.

akima · 2014-09-06T07:24:07Z

I just realised that "&monkeyfart!££" is actually a valid relative path name. What I said still holds, just replace "&monkeyfart!££" with ">elephant*dung?" (which contains the invalid characters: >*? ).

akima · 2014-09-06T07:31:12Z

eryksun: You have marked this bug as effecting Python 2.7. When I tested for the bug on 2.7.5 the problem didn't show up:

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

Did you independently test a later release of version 2.7 and find the issue? If not, could you remove Python 2.7 from the "Versions" list.

serhiy-storchaka · 2014-09-06T08:02:48Z

This is the consequence of recent backporting splitdrive() implementation from
3.x to 2.7.

eryksun · 2017-01-15T14:31:24Z

isabs also fails for device paths such as r"\\.\C:", which is an absolute path for opening the C: volume. UNC and device paths (i.e. \\server, \\?, and \\.) should always be considered absolute. Only logical drives (i.e. C:, D:, etc) support drive-relative paths.

Also, join() needs to be smarter in this case:

    >>> os.path.join(r'\\.\C:', 'spam')
    '\\\\.\\C:spam'

It doesn't insert a backslash because the 'drive' ends in a colon. It needs to always insert a backslash for UNC paths, which cannot be reliably identified by checking whether the last character of the drive is a colon.

eryksun · 2021-02-25T17:05:14Z

figure out whether to do Path.cwd() / path

Thus a UNC path is absolute, i.e. any path that starts with 2 or more slashes, and all other paths are relative unless they have both a drive and a root. For example:

    def isabs(s):
        """Test whether a path is absolute"""
        s = os.fspath(s)
        seps = _get_bothseps(s)
        if len(s) > 1 and s[0] in seps and s[1] in seps:
            return True
        drive, rest = splitdrive(s)
        if drive and rest:
            return rest[0] in seps
        return False

This also fixes the mistaken result that a rooted path such as "/spam" is absolute. When opened directly, a rooted path is relative to the drive of the current working directory. When accessed indirectly as the target of a symlink, a rooted path is relative to the volume device of the opened path.

An example of the latter is a symlink named "link" that targets "\". If it's accessed as E:\link, it resolves to E:\. If it's accessed as C:\Mount\VolumeE\link, it resolves instead to C:\. The relative link resolves differently depending on the path traversed to access it. (Note that when resolving the target of a relative symlink, mountpoints such as "VolumeE" that are traversed in the opened path do not get replaced by their target path, unlike directory symlinks, which do get replaced by their target path. This behavior is basically the same as the way mountpoints and symlinks are handled in Unix.)

barneygale · 2023-12-23T06:11:07Z

Would a new strict argument for isabs() help? It wouldn't affect how UNC paths (two leading slashes) are handled, as they're always absolute per Eryk's comment above, but otherwise:

isabs('blah', strict=None): true if the path has a root (default)
- Backwards-compatible but rarely useful
isabs('blah', strict=False): true if the path has either drive or a root
- Useful for checking if a path is entirely relative (negate its result)
isabs('blah', strict=True): true if the path has both a drive and a root
- Useful for checking if a path is entirely absolute

zooba · 2024-01-04T19:22:32Z

Would a new strict argument for isabs() help?

No, we should just strive for the most consistency. Testing for starting with two sep/altseps or {A-Z}:{sep} should be enough. And it should be consistent with how join() handles each segment.

If users really want to know whether a path is relative but has a drive segment, they can splitdrive.

barneygale · 2024-01-04T19:40:18Z

I think I misunderstood this bug, and thought it was a dupe of #44626.

This bug appears to be fixed in 3.12 by #29041 and #100351:

>>> import ntpath
>>> ntpath.isabs(r"\\server")
True
>>> ntpath.isabs(r"\\server\share")
True
>>> ntpath.isabs(r"\\server\share\folder")
True
>>> ntpath.isabs(r"\\server\share\folder\folder")
True

zooba · 2024-01-04T22:40:08Z

Yeah, it was fixed by that, but the fix then caused #112563 (which is already being looked into). So this one can be closed.

akima mannequin added stdlib Python modules in the Lib dir OS-windows labels Aug 29, 2014

akima mannequin added the type-bug An unexpected behavior, bug, or error label Aug 30, 2014

eryksun added the 3.7 (EOL) end of life label Jan 15, 2017

eryksun added 3.9 only security fixes 3.10 only security fixes and removed 3.7 (EOL) end of life labels Feb 25, 2021

ezio-melotti transferred this issue from another repository Apr 10, 2022

barneygale mentioned this issue Dec 27, 2023

Add os.path.isrelative() and improve ntpath.isabs() #44626

Closed

zooba closed this as completed Jan 4, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Windows os.path.isabs UNC path bug #66498

Windows os.path.isabs UNC path bug #66498

akima mannequin commented Aug 29, 2014

akima mannequin commented Aug 29, 2014

eryksun commented Aug 29, 2014

akima mannequin commented Aug 30, 2014

akima mannequin commented Sep 1, 2014

zooba commented Sep 5, 2014

pitrou commented Sep 5, 2014

zooba commented Sep 5, 2014

zooba commented Sep 5, 2014

serhiy-storchaka commented Sep 5, 2014

eryksun commented Sep 5, 2014

pitrou commented Sep 5, 2014

eryksun commented Sep 5, 2014

akima mannequin commented Sep 5, 2014

akima mannequin commented Sep 6, 2014

akima mannequin commented Sep 6, 2014

serhiy-storchaka commented Sep 6, 2014

eryksun commented Jan 15, 2017

eryksun commented Feb 25, 2021

barneygale commented Dec 23, 2023 •

edited

Loading

zooba commented Jan 4, 2024

barneygale commented Jan 4, 2024 •

edited

Loading

zooba commented Jan 4, 2024

Windows os.path.isabs UNC path bug #66498

Windows os.path.isabs UNC path bug #66498

Comments

akima mannequin commented Aug 29, 2014

akima mannequin commented Aug 29, 2014

eryksun commented Aug 29, 2014

akima mannequin commented Aug 30, 2014

akima mannequin commented Sep 1, 2014

zooba commented Sep 5, 2014

pitrou commented Sep 5, 2014

zooba commented Sep 5, 2014

zooba commented Sep 5, 2014

serhiy-storchaka commented Sep 5, 2014

eryksun commented Sep 5, 2014

pitrou commented Sep 5, 2014

eryksun commented Sep 5, 2014

akima mannequin commented Sep 5, 2014

akima mannequin commented Sep 6, 2014

akima mannequin commented Sep 6, 2014

serhiy-storchaka commented Sep 6, 2014

eryksun commented Jan 15, 2017

eryksun commented Feb 25, 2021

barneygale commented Dec 23, 2023 • edited Loading

zooba commented Jan 4, 2024

barneygale commented Jan 4, 2024 • edited Loading

zooba commented Jan 4, 2024

barneygale commented Dec 23, 2023 •

edited

Loading

barneygale commented Jan 4, 2024 •

edited

Loading