[issue12777] Inconsistent use of VOLUME_NAME_* with GetFinalPathNameByHandle

Eryk Sun added the comment: bpo-33016 fixed the problem with the inconsistent dwFlags argument passed to GetFinalPathNameByHandleW(). We do need the ability to get the NT name in order to implement samefile() and sameopenfile() reliably in all cases -- i.e. when the volume serial number and

[issue12777] Inconsistent use of VOLUME_NAME_* with GetFinalPathNameByHandle

Erlend Egeberg Aasland added the comment: This seems to have been fixed in 2018 in bpo-33016 by GH-6010. -- nosy: +erlendaasland ___ Python tracker ___ ___

[issue12777] Inconsistent use of VOLUME_NAME_* with GetFinalPathNameByHandle

Antoine Pitrou added the comment: That's slightly off-topic, but is it enough to strip the leading '\\?\' (and replace 'UNC' with '\'), or are there other things to watch out for? -- ___ Python tracker __

[issue12777] Inconsistent use of VOLUME_NAME_* with GetFinalPathNameByHandle

Jason R. Coombs added the comment: I agree the two calls should probably be consistent, though I also suspect that VOLUME_NAME_NT is always longer than VOLUME_NAME_DOS. My justification for using VOLUME_NAME_NT is that the final name might not be located on a DOS-accessible name. My suspicion

[issue12777] Inconsistent use of VOLUME_NAME_* with GetFinalPathNameByHandle

Brian Curtin added the comment: Adding Jason - I'll dig around for it, but I think I brought this up in the past and I seem to remember him having a justification for it. (apologies if I'm thinking of something else) -- nosy: +jason.coombs ___ Pyth

[issue12777] Inconsistent use of VOLUME_NAME_* with GetFinalPathNameByHandle

New submission from Antoine Pitrou : In the implementation of nt._getfinalpathname() (in posixmodule.c) we have: /* 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); [...] r