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.

[zooba]

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

What other functions do you mean?

It's possible there was more logic at play there than what is guiding this one, or it's also possible that they were merged by different committers following different logic.

Right now, I'm with @barneygale. Invalid paths are allowed to have invalid behaviour.

[nineteendo]

What other functions do you mean?

Probably just ntpath.splitroot(), which might have been accidentially fixed when the logic for handling the root was added.

[eryksun]

Right now, I'm with @barneygale. Invalid paths are allowed to have invalid behaviour.

I got an upvote from Barney that it would be better to make isabs() and splitroot() consistent, and splitroot() has the correct behavior. "/:" can never be a drive, and nothing in the Windows API will ever handle it as a drive. The system will try to resolve the path on the drive of the current working directory. Anyway, it isn't critical. It's an invalid path, and at best it's poorly supported by the VirtualBox shared-folder filesystem.

The choice made here should be consistent with whether nineteendo's other issue about calling normpath('/:) gets fixed or closed as won't fix. If it doesn't matter here that "/:" can never be a drive, then it doesn't matter there either. We'd just let normpath() handle "/:" as a drive.

[zooba]

Okay then, I'll phrase my preference as:

Expected: False, as /:/foo is not a valid absolute path

This means that if we had an isrelative function, it could also return False. We're in a NaN type situation here, which gives us fairly complete freedom to return whatever we like, since the input is not-a-path. Typically is* functions return False rather than raise, norm* type functions do garbage-in-garbage-out, and anything that actually needs to resolve the path should raise.

This also means we can wontfix normpath and fix this one, and it's perfectly consistent 😉

[nineteendo]

I probably should've mentioned this sooner, but this also breaks the fallback implementation for ntpath.abspath():

>>> import ntpath
>>> ntpath.abspath("/:/foo"), ntpath._abspath_fallback("/:/foo")
('C:\\:\\foo', '/:\\foo')

Ideally these should behave the same, and I think here fixing ntpath.isabs() and therefore the fallback implementation of ntpath.abspath() has the lowest risk. The separator will then be fixed automatically, regardless of whether ntpath.normpath() is fixed.

[barneygale]

I don't feel strongly about this, but for me the garbage-in-garbage-out principal applies to isabs(), splitroot() and normpath() equally, and allows the C and Python implementations to produce different values for the same invalid input. If this freedom allows us to add (or retain) a faster and/or more idiomatic implementation then we should use it.

[nineteendo]

OK, I'm closing this. If you change your mind this can be re-opened.