Eryk Sun <[email protected]> added the comment:
> Until then, I think it makes sense for os.readlink() to handle the
> prefix and _getfinalpathname() call, but leave nt.readlink() as
> returning the raw value.
os.readlink() shouldn't resolve the final path or realpath(). It should simply
return the link substitute path, which starts with "\\\\?\\". I'm wary of
trying to return it without the prefix. We would need a function that's shared
with the proposed implementation of realpath() to determine whether the given
path (not the final path) is safe to return as a normal DOS or UNC path.
---
BTW, I looked into how CreateFileW is supporting "\\??\\". It turns out at some
point they changed RtlpDosPathNameToRelativeNtPathName to look for both
"\\\\?\\" and "\\??\\" when determining whether to skip normalizing the path. I
think that's a bad idea since the Windows API doesn't consistently support the
NT prefix.
ReactOS is supposed to target NT 5.2 (Server 2003), and it doesn't allow the NT
prefix here. Refer to its implementation of
RtlpDosPathNameToRelativeNtPathName_Ustr [1]. It only looks for
RtlpWin32NtRootSlash ("\\\\?\\"), not RtlpDosDevicesPrefix ("\\??\\"). So I
suppose Windows changed this some time between Vista and Windows 10.
[1]
https://github.com/reactos/reactos/blob/d93e516747e3220ba182f77824e8b1a8b548edae/sdk/lib/rtl/path.c#L1034
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue37834>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
