nt.realpath() should use GetFinalPathNameByHandleW() when available, instead of GetFullPathNameW(), to resolve symlinks.

By the way, it's strange that Py_GetFinalPathNameByHandleW() is called with VOLUME_NAME_NT to get the buffer size, and then with VOLUME_NAME_DOS. Is it a bug?

    /* We have a good handle to the target, use it to determine the
       target path name. */
    buf_size = Py_GetFinalPathNameByHandleW(hFile, 0, 0, VOLUME_NAME_NT);

    if(!buf_size)
        return win32_error_object("GetFinalPathNameByHandle", po);

    target_path = (wchar_t *)malloc((buf_size+1)*sizeof(wchar_t));
    if(!target_path)
        return PyErr_NoMemory();

    result_length = Py_GetFinalPathNameByHandleW(hFile, target_path,
                                                 buf_size, VOLUME_NAME_DOS);

See also issue #9333 (issue which added os.symlink() on Windows).

I'm assuming that this should be treated as an enhancement request.

Python 3 now uses GetFinalPathNameByHandle()!

I assume by nt.realpath we're talking about ntpath.realpath. In that case nothing was done to fix this. It's still an alias for ntpath.abspath, which calls GetFullPathNameW.

Oh, only os.stat() was patched to use GetFinalPathNameByHandle()? It seems like most of the code was already written, so it shouldn't be hard to add a nt.GetFinalPathName() function using the win32_xstat_impl() code (and get_target_path()), to implement a real ntpath.realpath(), no?

@Eryk: Are you interested to work on a patch?

Any update on this issue?

I can give it a try.

Ping on PR 11248. It would be nice to get this into 3.8.

Posted a review. I suggest a few changes for the sake of tidying up, but I agree that I'd like to see more tests added.

As of 3.8, it (sort of) does.