ntpath.ismount() returns True for a UNC server with no share (e.g. \\server, \\?\UNC\server)

[amruthamodela06]

Bug report

Bug description:

On Windows, os.path.ismount() (ntpath.ismount()) returns True for UNC paths that have a server but no share component. A UNC mount point requires both a server and a share (\\server\share); a bare server name is not a mount point and should return False.

# Python 3.16.0a0 (current main, MSC v.1944 64-bit)
>>> import os.path
>>> os.path.ismount(r"\\server")        # server, no share
True
>>> os.path.ismount(r"\\?\UNC\server")  # extended UNC, server, no share
True

Genuine share roots correctly return True:

>>> os.path.ismount(r"\\server\share")
True
>>> os.path.ismount(r"\\?\UNC\server\share")
True

This is partly a regression. On 3.11:

>>> os.path.ismount(r"\\?\UNC\server")
False
>>> os.path.ismount(r"\\server")
OSError: [WinError 123] ...

So \\?\UNC\server changed from False to True. (The same change correctly fixed \\?\UNC\server\share, which was wrongly False on 3.11.)

Root cause:

Since the splitroot()-based rewrite in gh-101000, ismount does if drive and drive[0] in seps: return not rest. For an incomplete one-component UNC, splitroot(r"\\server") returns ('\\server', '', '') — the whole thing lands in drive with an empty tail — so it passes the share-root check despite there being no share.

Suggested fix:

Require both a server and a share component before treating a UNC drive as a mount root.

Split off from #139916 per @zooba's suggestion.

CPython versions tested on:

3.11, CPython main (3.16.0a0)

Operating systems tested on:

Windows

Linked PRs

• gh-150557: Fix os.path.ismount() for UNC paths with no share on Windows #150572

[zooba]

Just to add my thinking here (I haven't thought through these yet), the most important aspect of any change here will be the impact on other operations done by ntpath. For example, if join uses this to check how join(d, '..') behaves, the behaviour should get better (or stay the same) and not regress.

The actual result for ismount() on a value that is never actually valid is less important than the implications for whether other operations that derive from the result are sensible. "Garbage-in-garbage-out" allows us to say ismount(garbage) returns garbage, but we should also avoid join(garbage, ...) returning non-garbage.

[amruthamodela06]

Thanks! That framing makes sense, and I looked into it. The key point is that ntpath.ismount() is a leaf function: nothing in ntpath (or genericpath) calls it, and join / normpath / split / splitdrive are all driven by splitroot, not ismount. Its only consumer in the stdlib is pathlib.Path.is_mount(). So changing what ismount() returns for an invalid path can't ripple into any other operation — join(d, '..') and related operations are entirely independent of it.

Looking at the derived operations directly (which I'd leave untouched), the current behavior on these inputs already seems sensible and consistent:

join(r"\\server", "share")      -> r"\\server\share"
join(r"\\server", "foo", "bar") -> r"\\server\foo\bar"
join(r"\\server", "..")         -> r"\\server\.."
normpath(r"\\server\foo\..")    -> r"\\server\foo\"    # can't escape the share root
normpath(r"\\server\share\..")  -> r"\\server\share\"  # same as a real share

Since splitroot deliberately treats a partial UNC like \\server as an all-in-drive value (per the gh-96290 tests), join/normpath treat the first component after the server as the share — so appending yields a valid-looking share, which reads more like "complete the UNC" than garbage-out.

Given that, my proposed change is intentionally minimal and local to ismount: only treat a UNC drive as a mount point when it names both a server and a share. Device paths (\\.\dev, \\?\dev) and drive-letter roots are unaffected, and splitroot/join/normpath aren't touched at all. Happy to go broader (e.g. into splitroot) if you think the parsing primitives are the better place to address this, but that would have a much wider blast radius.

[zooba]

Thanks for being thorough, this sounds like a fine thing to fix then.

We might need to also update the docs to be clear that ismount->False doesn't necessarily imply that it's not a path to a mount point, just that ismount->True means that it is, but I think we clarified it recently to deal with directory mounts so it's probably fine.

[serhiy-storchaka]

What is the use case for this? How will it affect other code?

Currently, ismount is not used in the stdlib. The PR adds non-trivial amount of code, but I do not see what is the benefit of this change.

[amruthamodela06]

@serhiy-storchaka, Thanks for taking a look.

Use case: os.path.ismount() is a public API and pathlib.Path.is_mount() delegates to it. The bug makes both return True for \\server and \\?\UNC\server — UNC paths that name a server but no share, which are not mount points. Code using ismount() to detect filesystem boundaries (traversal, backup, dedup tools) gets a wrong answer for these inputs. It's also a regression from 3.11, introduced by the splitroot() rewrite in gh-101000.

Scope: pathlib.Path.is_mount() is the only stdlib caller and inherits the fix; nothing else in ntpath depends on ismount(). Genuine shares, device paths, and drive-letter roots are unaffected.

The added code volume mostly comes from str/bytes handling plus the \\?\UNC\ prefix — happy to revisit if it can be done more concisely.

Split out from gh-150557, where @zooba indicated this looks like a fine thing to fix.