Raymond informed me that #1578269 introduced breakage to compilation under Visual Studio 2005 due to three undefined symbols. I'm not currently setup to build under 2005, so I just offer this patch which defines the values as they are seen in VS 2008.

Applied in r84356.  
Thank you.

Can someone explain why among the 6 calls to Py_GetFinalPathNameByHandle, 5 of them use VOLUME_NAME_DOS and only one uses VOLUME_NAME_NT?

I committed the code you speak of (posix__getfinalpathname in Modules/posixmodule.c), but I don't know if I have a great answer for that question. It looks like VOLUME_NAME_NT (path with volume device path) should just be changed to VOLUME_NAME_DOS (path with drive letter). In fact, I think it would be more "accurate" since NT yields with a larger path, thus we over-allocate up front before we go on and use DOS and then trim the target path down.

Jason (author of that function, added as nosy) might have some other input as to why he used VOLUME_NAME_NT there.

In the case where I did use VOLUME_NAME_NT, I think I chose it because it returned a more robust result. That is, it's not clear what the result is if the result is not on a volume that is assigned a drive letter, but all files referenced must have a VOLUME_NAME_NT.

In other usage, I found that use of VOLUME_NAME_NT was unnatural, because it returned for the user a path that would be unfamiliar, rather than the more traditional VOLUME_NAME_DOS.

So, where the result is to be used by the interpreter and isn't exposed to the user, it seems prudent to use VOLUME_NAME_NT, and where the user will see the result, use VOLUME_NAME_DOS.

I admit, this is only a rule of thumb and may be subject to correction, but this was my motivation when making these selections.

The calls to Py_GetFinalPathNameByHandle come in pairs: one to get the length, the other to retrieve the value.  They should at least be consistent.
There are two other issues:

- in all three places, it's possible for the function to return after malloc(), but before the call to free(); and PyMem_Malloc()/PyMem_Free() would be better.

- on my windows XP, os.stat() is slower than before, and is now significantly slower than os.lstat() (26.6 usec -> 32.8 usec); I found that check_GetFinalPathNameByHandle() repeatedly checks for the presence of the function, and always calls GetModuleHandle() and GetProcAddress(). The attached patch fixes this, can you test it on Vista?

Your patch works for me on Win7.

I'll put together a patch for the malloc/free thing in your first bullet point.

Is this issue still valid?

I believe that this specific issue can be closed but is a follow up needed regarding problems mentioned in msg114084  ?

The original issue seems to be fixed, but the other two related issues mentioned by Amaury still need to be addressed.  One has already a patch, the other doesn't.

I believe the patch is obsolete. Python does not support Windows XP anymore, so all supported versions provide GetFinalPathNameByHandle, and all the detection code can go.

I believe that this can be closed as fixed, would someone like to do the honours please.

The patch is obsolete, but Martin is correct - we can drop the detection completely. Any concerns?

(Reading through the issue, there may be some value in a more general GetFinalPathNameByHandle wrapper that can get VOLUME_NAME_DOS if available and VOLUME_NAME_NT as a fallback, but presumably we'd have heard someone ask in the last five years if this was really needed.)

New changeset d094eeeb1496 by Steve Dower in branch 'default':
Closes #9445: Removes detection of GetFinalPathNameByHandle
https://hg.python.org/cpython/rev/d094eeeb1496