[issue32587] Make REG_MULTI_SZ support PendingFileRenameOperations

[Zackery Spytz]

Change by Zackery Spytz :


--
nosy: +ZackerySpytz

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32587] Make REG_MULTI_SZ support PendingFileRenameOperations

[Zackery Spytz]

Change by Zackery Spytz :


--
keywords: +patch
pull_requests: +13149
stage: needs patch -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32587] Make REG_MULTI_SZ support PendingFileRenameOperations

[Eryk Sun]

Eryk Sun  added the comment:

Currently countStrings and fixupMultiSZ halt the outer loop as soon as they hit 
an empty string. Basically, we'd be getting rid of that check. Then we have to 
prevent including an empty string for the final NUL in the normal case. We can 
do this by decrementing the length by 1 if the data ends on a NUL. We also need 
a check in the inner loop of fixupMultiSZ to ensure it doesn't get out of 
bounds. 

Example:

static void
fixupMultiSZ(wchar_t **str, wchar_t *data, int len)
{
int i;
wchar_t *P, *Q;

if (len > 0 && data[len - 1] == '\0') {
Q = data + len - 1;
} else {
Q = data + len;
}

for (P = data, i = 0; P < Q; P++, i++) {
str[i] = P;
for(; P < Q && *P != '\0'; P++)
;
}
}

static int
countStrings(wchar_t *data, int len)
{
int strings;
wchar_t *P, *Q;

if (len > 0 && data[len - 1] == '\0') {
Q = data + len - 1;
} else {
Q = data + len;
}

for (P = data, strings = 0; P < Q; P++, strings++) {
for (; P < Q && *P != '\0'; P++)
;
}
return strings;
}

Also, the REG_MULTI_SZ case in Reg2Py should use wcsnlen instead of wcslen, in 
case of malformed data that doesn't end on at least one NUL character. The 
upper limit would be the remaining length.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32587] Make REG_MULTI_SZ support PendingFileRenameOperations

[Seppo Yli-Olli]

Seppo Yli-Olli  added the comment:

I don't personally know enough of CPython (I barely know enough C) to do the 
patches but I'd just comment that as this might increase complexity of 
implementation and wide char API's are used, it might be prudent to make sure 
the new implementation works with some more exotic input than fits into ASCII. 
PendingFileRenameOperations can contain any valid Windows path. Microsoft also 
warns that the end null byte can be redacted in some cases by the party storing 
the data.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32587] Make REG_MULTI_SZ support PendingFileRenameOperations

[Steve Dower]

Steve Dower  added the comment:

I don't think it's too late (and I don't think this counts as a feature either, 
so the b1 deadline doesn't apply), but the patch would need to include an 
update to What's New as well as the usual stuff.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32587] Make REG_MULTI_SZ support PendingFileRenameOperations

[Eryk Sun]

Eryk Sun  added the comment:

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, 
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.

--
nosy: +eryksun
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47394/rtlqueryreg.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32587] Make REG_MULTI_SZ support PendingFileRenameOperations

[Ned Deily]

Change by Ned Deily :


--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32587] Make REG_MULTI_SZ support PendingFileRenameOperations

[Seppo Yli-Olli]

New submission from Seppo Yli-Olli :

MSDN documents that REG_MULTI_SZ is not supposed to have \0\0 anywhere else 
than in the end. The comment in  
https://github.com/python/cpython/blob/a5293b4ff2c1b5446947b4986f98ecf5d52432d4/PC/winreg.c#L504
clearly shows that Python has the assumption that this specification is 
actually correct. However, Microsoft is violating it eg in 
https://technet.microsoft.com/en-us/library/cc960241.aspx which prevents you 
from reading that registry key in Python at all. This is a list which is 
treated as pairs:
"""
foo

meep
bar
"""
so you can have empty items which in Windows semantics means "remove this 
file". This results in a string like "foo\0\0meep\0\bar\0\0". I'm proposing 
relaxing Python registry handling semantics because it's clearly Microsoft 
isn't following this either

--
messages: 310202
nosy: nanonyme
priority: normal
severity: normal
status: open
title: Make REG_MULTI_SZ support PendingFileRenameOperations

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com