Eryk Sun <[email protected]> added the comment:
> Windows getcwd() returns a path without resolved symbolic links
This provides consistency. If the working directory were resolved, then
accessing "../file.ext" after chdir("C:/Temp/link") could be inconsistent with
accessing "C:/Temp/link/../file.ext". This is a consequence of the way DOS
paths are translated to native NT paths, which is implemented strictly as a
string operation. Since "." and ".." are regular names in NT and not
necessarily reserved (e.g. FAT32 allows creating a file named ".."), resolving
a path POSIX style would require resolving it up to each ".." component. This
would entail potentially making many system calls just to normalize a path
before even getting to the intended operation.
> Use os.path.realpath() is you want to resolve symbolic links
In Windows, os.path.realpath is an alias for os.path.abspath, so it doesn't
resolve links. Use os.path._getfinalpathname to resolve a file-system path.
This returns a \\?\ local-device path, which I'd encourage retaining rather
than automatically converting to a regular DOS path. The resulting path may be
too long for a regular DOS path (if long paths aren't supported), or the final
component of the path may conflict with DOS quirks such as reserved device
names (e.g. "nul.txt") and ignoring trailing dots and spaces.
----------
nosy: +eryksun
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue1154351>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
