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.