Eryk Sun <eryk...@gmail.com> added the comment:
> >>> sys.executable
> 'X:\\Python38\\python.exe'
> >>> os.path.realpath(sys.executable)
> '\\\\SERVER\\Programs\\Python38\\python.exe'
Unix Python resolves the executable path with repeated _Py_wreadlink calls.
Windows Python should do something similar to ensure the consistency of
sys.executable with realpath(sys.executable).
> different from mapped network and subst drives (AFAIU).
Mapped and subst drives are implemented as object-manager symlinks to
file-system directories. For example, a subst drive "S:" might target a local
directory such as r"\??\C:\Temp\Subst", and a mapped drive "M:" for an SMB
share might target a path such as r"\Device\LanmanRedirector\;M:<logon
session>\Server\Share\Temp\Mapped".
The root directory of these drives does not behave like a real root directory
unless the drive targets the root of a volume or UNC share, such as
"\\??\\C:\\" or r"\Device\LanmanRedirector;M:<logon session>\Server\Share".
This means that in many cases it's possible to evaluate a relative symlink that
traverses above the drive root via ".." components. Say we have a directory
r"C:\Temp\Subst" that contains a relative symlink "foo_link" that targets
r"..\foo". If we map "S:" to r"C:\Temp\Subst", then r"S:\foo_link" opens
r"C:\Temp\foo". Similarly if we map r"\\localhost\C$\Temp\Subst" to "M:", then
r"M:\foo_link" opens r"C:\Temp\foo".
In the above case, if we're using relpath() to compute the relative path to the
"foo" target, I think we want relpath(realpath('C:/Temp/foo'), realpath('S:/'))
to succeed as r"..\foo". I don't think we want it to fail as a cross-drive
relative path.
----------
nosy: +eryksun
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue37993>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
