homepage

The implementation of nt._getfinalpathname leaks a File handle if calling GetFinalPathNameByHandle fails. The latter function is practically guaranteed to fail when resolving the path for a non-file-system device. It also fails when VOLUME_NAME_DOS is requested for a volume GUID path that isn't currently mounted as either a DOS drive letter or an NTFS junction. In this case requesting VOLUME_NAME_GUID should work.
For example, when I try calling _getfinalpathname to resolve the device paths \\?\MAILSLOT, \\?\PIPE, \\?\UNC, \\?\C:, \\?\PhysicalDrive0, \\?\NUL, \\?\CONIN,ドル and \\?\COM1, I get the following list of leaked handles:
 0x168 File \Device\Mailslot
 0x16c File \Device\NamedPipe
 0x178 File \Device\Mup
 0x17c File \Device\HarddiskVolume2
 0x180 File \Device\Harddisk0\DR0
 0x18c File \Device\Null
 0x194 File \Device\ConDrv
 0x198 File \Device\Serial0
(The above is from a context manager that checks for leaked handles using ctypes to call the PssCaptureSnapshot API, which was introduced in Windows 8.1. I think Process Snapshotting is the only Windows API that uses the kernel's ability to fork a clone of a process.) 
The reason that GetFinalPathNameByHandle fails in these cases is that the information classes it queries are typically only serviced by file systems. Other I/O devices (e.g. disk and volume devices) will fail these I/O requests. It happens that GetFinalPathNameByHandle starts with an NtQueryObject request that succeeds in these cases (it's the source of the above native NT device names), but it doesn't stop there. It continues requesting information from the device and the mount-point manager until it either has everything or a request fails.
Also, in os__getfinalpathname_impl, I notice that it's switching from VOLUME_NAME_NT in the first call that's used to get the buffer size to VOLUME_NAME_DOS in the second call. It should use VOLUME_NAME_DOS in both cases, or better yet, add a keyword-only argument to select a different volume-name style (i.e. None, DOS, GUID, or NT).

The os__getfinalpathname_impl handle leak and VOLUME_NAME_NT problems were fixed in another issue. However, PR 740 also includes fixes for handle leaks in os.stat, specifically in win32_xstat_impl and get_target_path.

Steve, can you review and merge PR 740? Mark updated it to fix the handle leaks in win32_xstat_impl as mentioned in my previous message. They're unlikely but still should be fixed. In particular, iIt's unlikely that win32_get_reparse_tag (i.e. FSCTL_GET_REPARSE_POINT) will fail, but not quite as unlikely that get_target_path (i.e. GetFinalPathNameByHandleW) will fail (e.g. it will fail if the target is on an ImDisk ramdisk).

We certainly shouldn't be calling CloseHandle on a parameter like this anyway, so the change looks good to me.
However, I notice that we don't necessarily preserve GetLastError() throughout here, so perhaps we ought to consider changing the return value interpretation at some point? (e.g. CloseHandle() may change it, and so we lose the actual error) That can be a future task though.

New changeset b82bfac4369c0429e562a834b3752e66c4821eab by Steve Dower (Mark Becwar) in branch 'master':
bpo-29734: nt._getfinalpathname handle leak (GH-740)
https://github.com/python/cpython/commit/b82bfac4369c0429e562a834b3752e66c4821eab

New changeset 63a69ef4a2390cea3e102498ac7eeeb5546e82b6 by Miss Islington (bot) in branch '3.7':
bpo-29734: nt._getfinalpathname handle leak (GH-740)
https://github.com/python/cpython/commit/63a69ef4a2390cea3e102498ac7eeeb5546e82b6

New changeset 6ef726af3ec106013c7c4261ddb306854f2b1778 by Berker Peksag in branch 'master':
bpo-29734: Cleanup test_getfinalpathname_handles test (GH-12908)
https://github.com/python/cpython/commit/6ef726af3ec106013c7c4261ddb306854f2b1778