Eryk Sun <eryk...@gmail.com> added the comment:
Windows resolve() is based on ntpath._getfinalpathname, which requires that the file exists and is accessible. resolve() defaults to non-strict behavior, which tries to resolve as much as possible by traversing the path in reverse and trying _getfinalpathname until it succeeds. For this to work reliably, it needs to begin with a fully-qualified path from ntpath._getfullpathname. This is also required in order to correctly resolve paths that have a reserved DOS device name in the final component (e.g. "nul", "nul:", "nul.txt") Additionally, for an empty path, resolve() returns os.getcwd(). I don't know whether this case occurs in practice, but the working directory has to be resolved in Windows the same as any other path. It's not already resolved. Also, the non-strict case should be relaxed like the POSIX version. It should continue resolving the path on any OSError, with possibly one exception. The POSIX version raises RuntimeError for a symlink loop. In Windows this case is ERROR_CANT_RESOLVE_FILENAME (1921). For cross-platform compatibility, this should probably be handled by raising the same RuntimeError. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue36860> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
