Author eryksun
Recipients eryksun, nanonyme, paul.moore, steve.dower, tim.golden, zach.ware
Date 2018-01-18.00:38:23
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1516235903.16.0.467229070634.issue32587@psf.upfronthosting.co.za>
In-reply-to
Content
PyWin32's win32api.RegQueryValueEx and win32api.RegEnumValue also use the same documented interpretation of REG_MULTI_SZ [1] (i.e. a "sequence of null-terminated strings, terminated by an empty string").

[1]: https://msdn.microsoft.com/en-us/library/ms724884

However, in practice Windows doesn't follow this literal interpretation. For example, the Session Manager (smss.exe) reads the "PendingFileRenameOperations" REG_MULTI_SZ value using the documented runtime library function RtlQueryRegistryValues [2]. By default, this function calls the specified QueryRoutine for each null-terminated string when reading a REG_MULTI_SZ value. 

[2]: https://msdn.microsoft.com/en-us/library/ff562046

I've verified that RtlQueryRegistryValues does not terminate the read on the first empty string, but instead continues to iterate through the entire value. See the attached test script, rtlqueryreg.py. The following output was obtained after two calls to MoveFileEx with the flag MOVEFILE_DELAY_UNTIL_REBOOT that pended operations to delete "foo" and rename "meep" to "bar":

    PendingFileRenameOperations, REG_SZ, \??\C:\Temp\foo
    PendingFileRenameOperations, REG_SZ, <empty>
    PendingFileRenameOperations, REG_SZ, \??\C:\Temp\meep
    PendingFileRenameOperations, REG_SZ, \??\C:\Temp\bar

Currently, winreg terminates reading this value at the first empty string. For example:

    >>> hkey = winreg.OpenKey(winreg.HKEY_LOCAL_MACHINE,
    ...     r'SYSTEM\CurrentControlSet\Control\Session Manager')
    >>> winreg.QueryValueEx(hkey, 'PendingFileRenameOperations')
    (['\\??\\C:\\Temp\\foo'], 7)

This behavior is inconsistent with Windows, which I think presents a strong case for the suggested change. As always, there's an issue with introducing breaking changes. It may be too late in the development cycle to introduce this change in 3.7.
History
Date User Action Args
2018-01-18 00:38:23eryksunsetrecipients: + eryksun, paul.moore, tim.golden, zach.ware, steve.dower, nanonyme
2018-01-18 00:38:23eryksunsetmessageid: <1516235903.16.0.467229070634.issue32587@psf.upfronthosting.co.za>
2018-01-18 00:38:23eryksunlinkissue32587 messages
2018-01-18 00:38:23eryksuncreate