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/itemdl... [2] https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/comdlg32/tests/itemdl... [3] https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/comdlg32/tests/itemdl... [4] https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/comdlg32/tests/itemdl... [5] https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/comdlg32/tests/itemdl...
Kind regards, Bernhard