This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eryksun
Recipients eryksun, paul.moore, steve.dower, tim.golden, zach.ware
Date 2019-08-16.02:48:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> So for an actual non-root mount point ntpath.ismount() returns True 
> and with IO_REPARSE_TAG_MOUNT_POINT included ntpath.islink() also 
> returns True. nt.readlink() returns the "\\?\Volume{GUID}\" path

If islink() is true, then st_mode has S_IFLNK and not S_IFDIR. So we have a mount point that's a symlink, which is not possible in POSIX, and it's not a directory, which is unusual in POSIX to say the least. 

For cross-platform consistency, I think it's better if ismount() is a directory. The question would be how to ensure that's true in all cases. Windows make this hard to accomplish reliably due to DOS 'devices' that get reparsed in the object manager to arbitrary paths, not necessarily to volume devices.

> Root mount points ("C:\\", etc.) do not return true for islink()

Not really. Here's a mountpoint-symlink chimera:

    >>> os.readlink('C:/Mount/Windows')
    >>> os.system('subst W: C:\\Mount\\Windows')

It's a symlink and not a directory:

    >>> os.path.islink('W:\\')
    >>> os.lstat('W:\\').st_mode & stat.S_IFDIR

But it's also a mount point:

    >>> os.path.ismount('W:\\')

The object manager reparses "W:" as "\\??\\C:\\Mount\\Windows", and we open it with a trailing backlash, which is fine, i.e. "\\??\\C:\\Mount\\Windows\\". 

> I'm not seeing why having both islink() and ismount() be true 
> in this case is a problem.

It's only possible if a mount point is not a directory. That we'd be returning this for a junction is a strange state of affairs because a junction must target a file system directory. I prefer generalizing junction as a name-surrogate type that allows S_IFDIR.
Date User Action Args
2019-08-16 02:48:33eryksunsetrecipients: + eryksun, paul.moore, tim.golden, zach.ware, steve.dower
2019-08-16 02:48:33eryksunsetmessageid: <>
2019-08-16 02:48:33eryksunlinkissue37834 messages
2019-08-16 02:48:33eryksuncreate