Eryk Sun added the comment:
It's the same with ntpath.abspath since the underlying GetFullPathName function
processes the path only as a string. OK, so it seems we're requiring that
p.absolute().resolve() is the same as p.resolve().
Consider the following example:
>>> p = Path('C:/symlink/../nul .eggs & spam')
>>> print(p.absolute())
C:\symlink\..\nul .eggs & spam
>>> print(os.path.abspath(p))
\\.\nul
If the current absolute() result is fine, then I think resolve() should return
\\.\nul, which means it needs to be expanded to handle device-path cases for
which _getfinalpathname fails. We should be able to handle these cases by
falling back on _getfullpathname. It's a separate issue, but here are some
concrete examples that currently cause resolve() to fail.
GetFinalPathNameByHandle will fail with ERROR_INVALID_FUNCTION or
ERROR_INVALID_PARAMETER for devices that aren't file systems and thus do not
support the particular NtQueryInformationFile and NtDeviceIoControlFile
information classes and IOCTLs that it requests. Also, getting a handle via
CreateFile can fail with ERROR_INVALID_PARAMETER for devices that require
either read or write access such as CON. It can also fail with
ERROR_ACCESS_DENIED for exclusive devices that are already open such as COM1.
ERROR_ACCESS_DENIED can also be due to the file security denying the right to
read attributes or synchronize since CreateFile implicitly requests those
rights. There's also ERROR_SHARING_VIOLATION when trying to open a system
paging file. These non-device PermissionError cases can be handled the same way
that resolve() currently handles FileNotFoundError by trying to resolve the
parent directory.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29688>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
