[issue9949] os.path.realpath on Windows does not follow symbolic links

[Steve Dower]

Steve Dower <steve.dower at python.org> added the comment:

FYI, there's been some discussion of this on issue37834, as the issues quickly became conflated.

There's also issue14094 which is a dup of this one, but with a different patch.

---

To move the relevant discussion here, my current PR is basically the tests from the last attached patch here plus a simpler implementation for non-strict resolution.

Right now the big open question is how to deal with the \\?\ prefix. My last two commits will leave it alone if it was in the initial path, and otherwise strip it if the non-prefixed path resolves to the same path as the prefixed path (the _getfinalpathname always returns a prefixed path).

The downside of this is that any unresolvable symlinks (dangling links, cycles, etc.) will now be returned with the prefix, whereas previously they were being returned without any attempt to resolve them being made (not because they are invalid, but because the old code wasn't attempting to resolve anything at all).

I kinda feel like this is okay, but would appreciate any other opinions on the matter. The alternative is to always strip the prefix, which could make some valid paths become invalid (for example, the one in the new test_realpath_symlink_prefix).

----------
nosy: +eryksun
versions: +Python 3.8, Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9949>
_______________________________________