May 2026 - Wine-Bugs - list.winehq.org

[Bug 59724] Far Manager v3.0 build 6666 x64 does NOT work in Wine

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59724 Artem S. Tashkinov <aros(a)gmx.com> changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |https://www.farmanager.com/ | |files/Far30b6666.x64.202603 | |24.7z Keywords| |download, source -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

May 5, 2026

[Bug 59724] New: Far Manager v3.0 build 6666 x64 does NOT work in Wine

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59724 Bug ID: 59724 Summary: Far Manager v3.0 build 6666 x64 does NOT work in Wine Product: Wine Version: 11.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: aros(a)gmx.com Distribution: --- wineconsole --backend={ncurses|user} Far.exe 002c:err:wineboot:process_run_key Error running cmd L"C:\\windows\\system32\\winemenubuilder.exe -a -r" (126). -> Silently exits while flashing a new window. Looks like the --backend option is ignored in Wine 11.8. ------------------------------------------------------------------------------ This results in a freeze. You see gibberish on the screen but no main window. wine Far.exe 002c:err:wineboot:process_run_key Error running cmd L"C:\\windows\\system32\\winemenubuilder.exe -a -r" (126). 0024:fixme:console:SetConsoleKeyShortcuts : (1 8 0000000000000000 0) stub! 00e4:fixme:kernelbase:AppPolicyGetThreadInitializationType FFFFFFFFFFFFFFFA, 00007FFFFEDFFF50 0024:fixme:file:NtLockFile I/O completion on lock not implemented yet rgb:e4/e4/e4 Far Manager, version 3.0.6666.0 x64 Copyright © 1996-2000 Eugene Roshal, Copyright © 2000-2026 Far Group 0024:fixme:volume:GetVolumeNameForVolumeMountPointW Mounted Folders are not yet supported 0024:fixme:volume:GetVolumeNameForVolumeMountPointW Mounted Folders are not yet supported 013c:fixme:explorerframe:taskbar_list_SetProgressState iface 00007FFFFE8AB400, hwnd 000000000001005C, flags 1 stub! 0024:fixme:file:GetLongPathNameW UNC pathname L"\\\\?\\C:\\users\\birdie\\AppData\\Roaming\\Far Manager\\Profile\\Plugins" 0024:fixme:volume:GetVolumeNameForVolumeMountPointW Mounted Folders are not yet supported 0024:fixme:volume:GetVolumeNameForVolumeMountPointW Mounted Folders are not yet supported 0150:fixme:console:process_csi_sequence unhandled sequence L"?61;1;21;22;28c\001b[?2026;4$y\001b[?61;1;21;22;28c" 0150:fixme:console:process_csi_sequence unhandled sequence L"?2026;4$y\001b[?61;1;21;22;28c" 0150:fixme:console:process_csi_sequence unhandled sequence L"?61;1;21;22;28c" ------------------------------------------------------------------------------ Older Far versions (can't say which) work. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

May 5, 2026

[Bug 59680] Path of Exile: font rendering related crash

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59680 Vitor Coimbra <vitorcoliveira91(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|10.0 |11.0 --- Comment #3 from Vitor Coimbra <vitorcoliveira91(a)gmail.com> --- Ok, well, I managed to reproduce this on something simpler than Path of Exile, namely Sublime Text. Here's the updated reproduction steps (on wine-11.0). 1. Download Sublime Text Windows portable version (from https://www.sublimetext.com/download) 2. Extract its .zip contents into some directory (e.g., "sublime/") 3. Copy this character (U+0065 U+0E4B): e๋ 4. cd sublime 5. wine sublime_text.exe 6. The text editor should open with a blank window. 7. Click on File on the upper left corner of the window. 8. Click Open File... 9. Paste that character into the "File name:" input field. 10. Immediate crash. Slight side note for NixOS users: for anyone else testing on NixOS, the wine package is not the proper way to install wine. Instead, use the wine64Packages.stableFull package, that brings in the binary and everything else it needs to actually properly run. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

May 5, 2026

[Bug 59723] SetSecurityInfo does not persist DACL changes

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59723 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #2 from Zeb Figura <z.figura12(a)gmail.com> --- This is essentially a duplicate of bug 33576, but even there it's not clear that there was ever an application that really needed this. Is there anything that needs it other than unit tests? I'm not sure that unit tests are enough of a reason to implement this feature. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

May 5, 2026

[Bug 59723] SetSecurityInfo does not persist DACL changes

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59723 Joel Holdsworth <joel(a)airwebreathe.org.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu(a)mailbox.org -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

May 5, 2026

[Bug 59722] RemoveDirectoryW fails with ERROR_SHARING_VIOLATION after subprocess exit

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59722 --- Comment #1 from Joel Holdsworth <joel(a)airwebreathe.org.uk> --- Created attachment 80871 --> http://bugs.winehq.org/attachment.cgi?id=80871 reproducer.exe -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

May 5, 2026

[Bug 59723] SetSecurityInfo does not persist DACL changes

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59723 --- Comment #1 from Joel Holdsworth <joel(a)airwebreathe.org.uk> --- Created attachment 80870 --> http://bugs.winehq.org/attachment.cgi?id=80870 reproducer.exe -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

May 5, 2026

[Bug 59723] New: SetSecurityInfo does not persist DACL changes

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59723 Bug ID: 59723 Summary: SetSecurityInfo does not persist DACL changes Product: Wine Version: 11.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: joel(a)airwebreathe.org.uk Distribution: --- Created attachment 80869 --> http://bugs.winehq.org/attachment.cgi?id=80869 reproducer.c (Found by AI testing) `SetSecurityInfo()` reports `ERROR_SUCCESS` when called to replace a file's DACL, but the DACL is not actually modified. Reading the DACL back (via either `GetSecurityInfo()` or `GetNamedSecurityInfoW()`) returns the original unchanged DACL. This also affects `SetNamedSecurityInfoW()`. ## Impact on MSYS2 The MSYS2/Cygwin runtime implements `chmod()` by translating POSIX mode bits into Windows ACL entries and calling `NtSetSecurityObject()` (which `SetSecurityInfo` wraps). Because the DACL is never actually updated: - `chmod()` appears to succeed but has no effect - `stat()` reads back the original permissions, not the ones set - `access()` checks against the wrong permissions - `umask()` has no observable effect on file creation modes This is the root cause for at least 6 test failures in the MSYS2 test suite: | Test | Symptom | |------|---------| | chmod01 | `chmod(0000)` → `stat()` still shows 0444; all 8 mode changes fail | | stat02 | `stat()` reports wrong mode after `chmod()` | | access01 | `access(file, X_OK)` wrong result because permissions unchanged | | access05 | `access()` returns 0 instead of -1 for file with read removed | | umask03 | Created files have wrong mode — umask bits not applied via ACL | | unlink08 | Directory permission changes don't take effect (partial overlap) | ## Reproducer ``` x86_64-w64-mingw32-gcc -o reproducer.exe reproducer.c -ladvapi32 wine reproducer.exe ``` ### Expected output (real Windows) ``` --- Step 2: Set DACL to single ACE (owner read-only) --- PASS: SetEntriesInAcl (1 ACE, read-only) PASS: SetSecurityInfo (protected DACL) --- Step 3: Read back DACL via handle --- PASS: GetSecurityInfo (re-read) After SetSecurityInfo: 1 ACEs [0] type=0 flags=0x00 mask=0x00120089 sid=S-1-5-21-...-1000 PASS: DACL has exactly 1 ACE PASS: ACE[0] is ACCESS_ALLOWED PASS: ACE[0] mask includes FILE_GENERIC_READ PASS: ACE[0] mask does NOT include GENERIC_WRITE bits ``` ### Actual output (Wine 11.4) ``` --- Step 2: Set DACL to single ACE (owner read-only) --- PASS: SetEntriesInAcl (1 ACE, read-only) PASS: SetSecurityInfo (protected DACL) --- Step 3: Read back DACL via handle --- PASS: GetSecurityInfo (re-read) After SetSecurityInfo: 3 ACEs [0] type=0 flags=0x00 mask=0x001f01ff sid=S-1-5-18 [1] type=0 flags=0x00 mask=0x001f01ff sid=S-1-5-21-0-0-0-1000 [2] type=0 flags=0x00 mask=0x001200a9 sid=S-1-1-0 FAIL: DACL has exactly 1 ACE (GetLastError=0) ``` The DACL still has 3 ACEs with the original permissions after the set call. ## Environment - Wine: 11.4 - Host: Linux x86_64 - Filesystem: ext4 (via wineprefix) ## Analysis The bug is in Wine's implementation of `NtSetSecurityObject()` (or the `SetSecurityInfo()` / `SetNamedSecurityInfoW()` wrappers). The function accepts the new security descriptor without error but does not write the new DACL to the underlying file's extended attributes or other backing store that Wine uses for ACL persistence. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

May 5, 2026

[Bug 59722] RemoveDirectoryW fails with ERROR_SHARING_VIOLATION after subprocess exit

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59722 Joel Holdsworth <joel(a)airwebreathe.org.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu(a)mailbox.org -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

May 5, 2026

[Bug 59722] New: RemoveDirectoryW fails with ERROR_SHARING_VIOLATION after subprocess exit

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59722 Bug ID: 59722 Summary: RemoveDirectoryW fails with ERROR_SHARING_VIOLATION after subprocess exit Product: Wine Version: 11.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)list.winehq.org Reporter: joel(a)airwebreathe.org.uk Distribution: --- Created attachment 80868 --> http://bugs.winehq.org/attachment.cgi?id=80868 reproducer.c (Found by AI testing) After a subprocess exits that had its current working directory set to a given directory, `RemoveDirectoryW()` on that directory fails with `ERROR_SHARING_VIOLATION` (error code 32). Wine does not properly release the directory handle that was used as the subprocess's CWD after the process terminates. On real Windows, removing the directory succeeds immediately after the subprocess exits. ## Impact on MSYS2 The MSYS2/Cygwin runtime maps `ERROR_SHARING_VIOLATION` to `EBUSY` (errno 16). Many MSYS2 test suite tests create a temporary directory, `fork()` + `exec()` a child process (which inherits the CWD), wait for the child to exit, then call `rmdir()` to clean up. Under Wine, this cleanup fails with `EBUSY`, causing the test harness to report failures even though the actual test logic passed. Affected tests include: | Test | Symptom | |------|---------| | fcntl07 | All 2 test cases PASS, but cleanup rmdir fails with EBUSY | | fcntl07B | Test case PASSES, but cleanup rmdir fails with EBUSY | ## Reproducer ``` x86_64-w64-mingw32-gcc -o reproducer.exe reproducer.c -lntdll wine reproducer.exe ``` ### Expected output (real Windows) ``` === Test 3: rmdir after subprocess with CWD in target dir === PASS: CreateDirectory PASS: RemoveDirectory after subprocess exit ``` ### Actual output (Wine 11.4) ``` === Test 3: rmdir after subprocess with CWD in target dir === PASS: CreateDirectory FAIL: RemoveDirectory after subprocess exit (GetLastError=32) Error: 32 ``` Error 32 is `ERROR_SHARING_VIOLATION`, indicating Wine still holds an internal reference to the directory after the subprocess has exited. ## Analysis When Wine creates a process with a CWD in a target directory, it opens a handle to that directory. When the process exits, Wine should close this handle so that the directory is no longer held open. Instead, the handle appears to leak or be released asynchronously, causing an immediate `RemoveDirectoryW` to hit a sharing violation. The underlying NT status is `STATUS_SHARING_VIOLATION`, which occurs because the directory still has an open handle without compatible sharing modes. ## Environment - Wine: 11.4 - Host: Linux x86_64 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

May 5, 2026