Handle `/:/` for `ntpath.isabs`

[nineteendo]

Bug report

Bug description:

>>> import ntpath
>>> ntpath.isabs("/:/foo")
True

Expected: False, as /:/foo is relative to the drive or UNC share of the current working directory.

CPython versions tested on:

CPython main branch

Operating systems tested on:

Windows

Linked PRs

• gh-117352: Handle /:/ for ntpath.isabs #117362

[eryksun]

Returning False for "/:foo" is the correct behavior starting with 3.13. Barney fixed ntpath.isabs() in the PR for #44626.

On Windows, "/:foo" is a rooted path, but it's not an absolute path. When a rooted path is opened directly, it's relative to the drive or UNC share of the current working directory. When a rooted path is the target path of a symlink, it's relative to the drive or UNC share of the opened path of the symlink.

Note that "/:foo" also happens to be invalid in practice, because ":" is reserved by Microsoft's filesystems as an illegal filename character. NTFS and ReFS use colon as the separator in file stream names (e.g. "filename:streamname:streamtype", such as "spam:eggs:$DATA").

[nineteendo]

Yeah, you're right. But, for this exact reason /:/foo would be not an absolute path.
I've updated the bug report reflecting this.

[barneygale]

/:/ is a totally unusable path right? Not convinced this is worth fixing (yet).

[nineteendo]

Eh, why do the other functions need to handle it correctly then? If you follow the same logic, these wouldn't have been accepted.

[eryksun]

/:/ is a totally unusable path right? Not convinced this is worth fixing (yet).

It's possible that a non-Microsoft filesystem on Windows might allow creating a directory named ":", but that's not explicitly supported by Microsoft. Still, I'd prefer to keep the implementation generic and in principle behave the same as checking for a drive and root via splitroot(), but without the cost of splitroot().

>>> os.path.splitroot('/:/foo')
('', '/', ':/foo')

Also, pathlib.PurePath.is_absolute() uses ntpath.isabs(), so it has a similar issue:

>>> pathlib.Path('/:/foo').drive
''
>>> pathlib.Path('/:/foo').root
'\\'

But

>>> pathlib.Path('/:/foo').is_absolute()
True

[nineteendo]

Fun fact: You can actually create a directory named ":" on a USB stick on Linux, but Windows treats that as \uf022 (private use).

[eryksun]

Fun fact: You can actually create a directory named ":" on a USB stick on Linux, but Windows treats that as \uf022 (private use).

I guess you mean creating a directory named ":" in a Microsoft filesystem type (e.g. FAT32, NTFS), assuming the Linux driver is configured to allow it. In that case, maybe the driver on Linux is what translates the reserved character to the private use area, or maybe it's done at access time by the filesystem driver on Windows, but mostly likely not by the system I/O manager (i.e. system Io* API) or Filesystem Runtime Library (i.e. system FsRtl* API). It's probably the same for other reserved filesystem characters, such as \, | or one of the 5 wildcard characters *?<>".

The example I had in mind is the VirtualBox shared-folder filesystem, which is lenient about accessing names in the host filesystem (e.g. a Linux host running a Windows guest). But the shared-folder filesystem driver is also broken in many cases. For example, it can open a directory named ":" to set it as the current working directory of a process, but trying to open files in the directory causes the driver to fail with STATUS_OBJECT_PATH_SYNTAX_BAD (0xC000003B). That's probably due to inconsistent use of the Filesystem Runtime Library.

[nineteendo]

I can confirm it's the Linux driver: \uf022 is treated as :, but I wanted to try just in case it would work.