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 report@bugs.python.org http://bugs.python.org/issue29688 _______________________________________