testbot final screenshot (Re: [PATCH] comdlg32: Avoid crash in RemoveControlItem.)

Bernhard Übelacker bernhardu at mailbox.org
Sat Dec 11 17:14:19 CST 2021


Am 11.12.21 um 19:41 schrieb Francois Gouget:
> On Sat, 11 Dec 2021, Bernhard Übelacker wrote:
> [...]
>> This hang with this "File not found" message
>> seems to be caused by the test started with current directory in
>> public documents, where also the test files get generated.
> 
> While most of the TestBot VMs start the tests in public documents, they
> may start them in other places. One VM started them from e:\ (though
> that may have been a Vista VM so moot now).
> 
> In any case the tests cannot make assumptions on what the current
> directory will be. So if comdlg32:itemdlg needs to be run in the user's
> Documents directory, then it should chdir there, no matter what the
> initial directory was.
> 
> 
>> Therefore cannot find them in my documents.
> 
> I did not go through the test code in detail so I may ask a stupid
> question. But why does the dialog look for the files in the user's
> documents folder?
> 
> Is it because the dialog is opened with an option that says to show the
> content of the user's documents folder?
> 
> If so then maybe the test files should be created there and then
> changing the current directory would not even be needed.
> 
> Or maybe the dialog could be told to open the current directory instead,
> though that may be less reliable (e.g. is cwd == c:\ )
> 


As far as I saw the test makes no assumptions about the path being started from.
It queries the current directory [1], creates some file inside [2],
and creates the file open dialog [3] and sets the initial directory to the
path queried before (through an IShellItem object).

Until now every path observed was C:\Users\Public\Documents,
where the test was started from (at this VM).

Then the OK is simulated [5].
If short before this point the dialog is queried (again via conversion
through an IShellItem), then it returns C:\Users\winetest\Documents.

I have tried to directly convert the IShellItem back to a real path,
but there it returned the input from the beginning, the current directory.

Also I have tried to change current directory at process start to just C:\Users\winetest,
and there the dialog did not hang, all "open" dialogs showed this path.

Therefore I assume that this is some special handling of
the C:\Users\winetest\Documents / C:\Users\Public\Documents directories,
at Microsoft side.


I proposed already following patch, which changes
current directory, in case we expect an issue:
https://source.winehq.org/patches/data/222000
Otherwise it operates where it got started from.


[1] https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/comdlg32/tests/itemdlg.c#l1520
[2] https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/comdlg32/tests/itemdlg.c#l1525
[3] https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/comdlg32/tests/itemdlg.c#l1394
[4] https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/comdlg32/tests/itemdlg.c#l1410
[5] https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/comdlg32/tests/itemdlg.c#l220

Kind regards,
Bernhard



More information about the wine-devel mailing list