Eryk Sun <[email protected]> added the comment:
os.readlink() was generalized to support mountpoints (junctions) as well as
symlinks, and it's more common for mountpoints to lack the print name field in
the reparse data buffer [1]. For example, PowerShell's new-item creates
junctions that only have a substitute path. This is allowed since the
filesystem protocols only require that the substitute path is valid in the
reparse data buffer, since that's all that the system actually uses when
resolving the reparse point.
The substitute path in the reparse point is a \\?\ prefixed path (actually a
\??\ NT path, but they're effectively the same for our purposes). This type of
path is usually called an extended path -- or an extended device path, or
verbatim path. It's a device path, like the \\.\ prefix, except that (1) it's
verbatim (i.e. not normalized), (2) its length is never limited to MAX_PATH
(260) characters, and (3) the Windows file API supports the \\?\ prefix more
broadly than the \\.\ prefix.
You're right that some programs can't grok an extended path. Some can't even
handle any type of UNC path. I agree that we need a simple way to remove the
prefix. I just don't agree that removing it should be the default behavior in
nt.readlink(), which I prefer to keep efficient and free of race conditions.
os.path.realpath() isn't necessarily what you want since it resolves the final
path. The link may target a path that traverses any number of reparse points
and mapped drives, so the final path may be completely different from the
os.readlink() result. We simply need an option to remove the \\?\ or \\?\UNC
prefix, either always or only when the path doesn't require it. It could be
implemented by a high-level wrapper function in os.py.
---
Reasons the prefix may be required
If the length of the target path exceeds MAX_PATH, then removing the prefix may
render the path inaccessible if the current process doesn't support long paths
without it (e.g. Windows 10 without long paths enabled at the system level, or
any version prior to Windows 10).
Also, reserved DOS device names are only accessible using an extended path. Say
I have the following "spam" junction:
>>> print(os.readlink('spam'))
\\?\C:\Temp\con
The junction allows accessing the target directory normally:
>>> stat.S_ISDIR(os.stat('spam').st_mode)
True
But look what happens when I try to access the target path without the prefix:
>>> stat.S_ISDIR(os.stat(r'C:\Temp\con').st_mode)
False
>>> stat.S_ISCHR(os.stat(r'C:\Temp\con').st_mode)
True
Instead of the directory that one might expect, it's actually a character
device!? Let's see what Windows opens:
>>> print(os.path.abspath(r'C:\Temp\con'))
\\.\con
It opens the "CON" device, for console I/O. It turns out that a bunch of names
are reserved, including NUL, CON, CONIN$, CONOUT$, AUX, PRN, COM<1-9>, and
LPT<1-9>. They're reserved even with an extension introduced by a colon or dot,
preceded by zero or more spaces. For example:
>>> print(os.path.abspath(r'C:\Temp\con :whatever'))
\\.\con
Directly accessing such a name in the filesystem requires a verbatim path. For
example:
>>> stat.S_ISDIR(os.stat(r'\\?\C:\Temp\con').st_mode)
True
Using reserved names is cautioned against, but in the real world we have to be
defensive. We can't simply remove the prefix and hope for the best.
---
[1]
https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/ns-ntifs-_reparse_data_buffer
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue42957>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
