[PATCH 0/1] MR7705: setupapi: Respect ERROR_SHARING_VIOLATION from open KnownDLL file handles.

[William Horvath (＠whrvt)]

create_dest_file was unaware of the `FILE_SHARE_READ | FILE_SHARE_DELETE` share mode that these SessionMgr entries are opened with. This avoids noisy `(error=80)` messages during prefix creation/update.

Fixes: 81ea1e7a20c9cd0698c0416282d9ad7c0109e865

[PATCH 1/1] setupapi: Respect ERROR_SHARING_VIOLATION from open KnownDLL file handles.

[William Horvath]

From: William Horvath

create_dest_file was unaware of the FILE_SHARE_READ | FILE_SHARE_DELETE share
mode that these SessionMgr entries are opened with. This avoids noisy
(error=80) messages during prefix creation/update.

Fixes: 81ea1e7a20c9cd0698c0416282d9ad7c0109e865
---
 dlls/setupapi/fakedll.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/dlls/setupapi/fakedll.c b/dlls/setupapi/fakedll.c
index b1f56b00619..bd3dfc95d38 100644
--- a/dlls/setupapi/fakedll.c
+++ b/dlls/setupapi/fakedll.c
@@ -505,7 +505,8 @@ static HANDLE create_dest_file( const WCHAR *name, BOOL delete )
         SetFilePointer( h, 0, NULL, FILE_BEGIN );
         SetEndOfFile( h );
     }
-    else if (!delete)
+    else if (!(GetLastError() == ERROR_SHARING_VIOLATION /* SessionMgr KnownDLLs entry */
+             || delete))
     {
         if (GetLastError() == ERROR_PATH_NOT_FOUND) create_directories( name );

[William Horvath (＠whrvt)]

Superseded by 0518efe87be8038bf1e8a1fef67ae9d1948121e8.

[PATCH 0/1] MR7705: setupapi: Respect ERROR_SHARING_VIOLATION from open KnownDLL file handles. - closed

[William Horvath (＠whrvt)]

This merge request was closed by William Horvath.

[Mitch Wilkinson (＠mitchwilkinson)]

William, can you please explain how `create_dest_file()` could bump into `ERROR_SHARING_VIOLATION` error on SessionMgr entries (KnownDLLs)?  I mean, `update_wineprefix()` is called **before** `create_known_dlls()` after patch 81ea1e7a20c (wineboot: Create section objects for known dlls., 2025-03-31).  How those functions may interfere between each other?

[William Horvath (＠whrvt)]

The section objects are created with `OBJ_PERMANENT` and a specific sharing mode (`FILE_SHARE_READ | FILE_SHARE_DELETE`) by wineboot, and it's done once for each prefix architecture (system32/syswow64). That permanent object is still open on the second go-around (next architecture), so when the setup tried to open that object with a different sharing mode, it ran into `ERROR_SHARING_VIOLATION`.

Refer to this documentation if that still wasn't clear:

https://learn.microsoft.com/en-us/windows/win32/fileio/creating-and-opening-...

https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-creat...

https://learn.microsoft.com/en-us/windows/win32/api/ntdef/ns-ntdef-_object_a...

[Mitch Wilkinson (＠mitchwilkinson)]

William, thanks for explanations and links!  But...
> when the setup tried to open that object with a different sharing mode

You mean dlls/setupapi?  Which is loaded by `update_wineprefix()` and programs/rundll32. Which is "run" by `update_wineprefix()`.  But the latter is called **before** the section objects are created.  So, why `create_dest_file()` would bump into `ERROR_SHARING_VIOLATION` error, if it is called when no section was created yet?  Someone runs wineboot twice?

[William Horvath (＠whrvt)]

Run a Wine build from the commit after 81ea1e7a20c9cd0698c0416282d9ad7c0109e865 with `WINEDEBUG=wineboot,setupapi,file wine wineboot -u` and see for yourself. How did you even come across this closed MR? Why is this of interest to you? The issue is already fixed in upstream Wine in a more proper manner.

[Mitch Wilkinson (＠mitchwilkinson)]

William, sorry I was bothering you.  Thanks for you information, once again.  Your MR is "directly" related to dlls/setupapi and `create_dest_file()` function -- that's why.  I just wanted to understand your changes and changes made by patch 81ea1e7a20c (wineboot: Create section objects for known dlls., 2025-03-31) because they relate to `create_dest_file()`.  And I saw/see no other appropriate place for such questions.

Thanks.