- Wine-Bugs - list.winehq.org

[Bug 59738] New: GetFinalPathNameByHandleW returns unresolved symbolic link path instead of final resolved path
by WineHQ Bugzilla May 15, 2026

May 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=59738 Bug ID: 59738 Summary: GetFinalPathNameByHandleW returns unresolved symbolic link path instead of final resolved path Product: Wine Version: 11.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: rikul(a)inbox.ru Distribution: --- Created attachment 80903 --> http://bugs.winehq.org/attachment.cgi?id=80903 The archive contains a minimal reproducer and a prebuilt executable demonstrating the issue. According to Microsoft documentation, GetFinalPathNameByHandleW() is expected to return the fully resolved final path for the object referenced by the handle. The documentation explicitly states: “A final path is the path that is returned when a path is fully resolved. For example, for a symbolic link named C:\tmp\mydir that points to D:\yourdir, the final path would be D:\yourdir.” Wine currently returns the original unresolved path containing the symbolic link component instead of the resolved target path. This differs from native Windows behavior and breaks applications relying on canonical filesystem paths. The issue also affects std::filesystem::weakly_canonical, which internally depends on GetFinalPathNameByHandleW. Steps to reproduce ------------------ Create a symbolic link: 1. touch /tmp/real.txt 2. ln -s /tmp/real.txt /tmp/link.txt 3. wine symlink_test.exe /tmp/link.txt. The program opens link.txt and calls GetFinalPathNameByHandleW() on the handle. Expected behavior ------------------ Input path: /tmp/link.txt GetFinalPathNameByHandleW result: \\?\Z:\tmp\real.txt std::filesystem::weakly_canonical result: Z:\tmp\real.txt The returned path is fully resolved and does not contain the symbolic link component. Actual behavior --------------- Input path: /tmp/link.txt GetFinalPathNameByHandleW result: \\?\Z:\tmp\link.txt std::filesystem::weakly_canonical result: Z:\tmp\link.txt Wine returns the unresolved original path used to open the handle. Regression information ---------------------- A git bisect identifies the following commit as the first bad commit: https://gitlab.winehq.org/wine/wine/-/commit/af35741d3681f21222a85900b54d95… Before this commit, GetFinalPathNameByHandleW() returned the resolved canonical path correctly. Tested on Wine 11.0 -- 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.

1 12

[Bug 59752] New: PROFILE_Save does not separate sections with empty line, leading to Ressource Hacker saving different ini file on 1st and 2nd run
by WineHQ Bugzilla May 15, 2026

May 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=59752 Bug ID: 59752 Summary: PROFILE_Save does not separate sections with empty line, leading to Ressource Hacker saving different ini file on 1st and 2nd run Product: Wine Version: 11.7 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)list.winehq.org Reporter: kyle.kcsoftwares(a)gmail.com Distribution: --- Resource Hacker 4.7.34 : https://web.archive.org/web/20180426130124if_/http://www.angusj.com/resourc… On first run, .ini file is created in the following format [Section1] Name1=Val1 Name2=Val2 Name3=Val3 [Section2] Name4=Val4 Name5=Val5 Name6=Val6 After second run, .ini file is rewritten in the folowing format [Section1] Name1=Val1 Name2=Val2 Name3=Val3 [Section2] Name4=Val4 Name5=Val5 Name6=Val6 In Windows, it is written as 2nd run from the initial start. Analysis performed here with API Monitor https://jira.reactos.org/browse/CORE-15438?focusedId=147696&page=com.atlass… show that " When Resource Hacker closes: - It checks for the ResourceHacker.ini file - If it is not present, it writes the initial contents using WriteFile (the text before the [MRU List] section - 277 bytes). The buffer of the application contains the double newlines as section separator. The handle is closed and the file is persistent on disk. - It calls WritePrivateProfileStringW for each MRU (1 to 8) - so 8 times - If the section [MRU List] is present, each MRU* entries are updated according (second time and further runs) - If the section [MRU List] is not present (like the first time you close the program), the section is created and the entire .ini file is rebuilt by the PROFILE_Save logic. The profile saving routine puts single new lines as section separator. - If it is present, it will read the memory the content, updates via WritePrivateProfileStringW and resave the content (those 347 bytes) " The guilty code is in kernel32/section.c PROFILE_Save which misses the additional CRLF between sections https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/kernel32/profile.c#L… -- 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.

1 1

[Bug 59751] New: WizTree 4.30: Dropdown menu fails to redraw hovered items with active visual style
by WineHQ Bugzilla May 15, 2026

May 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=59751 Bug ID: 59751 Summary: WizTree 4.30: Dropdown menu fails to redraw hovered items with active visual style Product: Wine Version: 11.7 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: kyle.kcsoftwares(a)gmail.com Distribution: --- Created attachment 80933 --> http://bugs.winehq.org/attachment.cgi?id=80933 Dropdown menu screenshot https://diskanalyzer.com/files/archive/wiztree_4_30_setup.exe WizTree 4.30 download link Dropdown menu fails to redraw hovered items with active visual style of WizTree -- 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.

1 1

[Bug 59729] New: Volumes do not report FILE_SUPPORTS_OPEN_BY_FILE_ID
by WineHQ Bugzilla May 14, 2026

May 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=59729 Bug ID: 59729 Summary: Volumes do not report FILE_SUPPORTS_OPEN_BY_FILE_ID Product: Wine Version: 11.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mountmgr.sys Assignee: wine-bugs(a)list.winehq.org Reporter: joel(a)airwebreathe.org.uk Distribution: --- Created attachment 80883 --> http://bugs.winehq.org/attachment.cgi?id=80883 reproducer.c (AI-assisted report) Wine's `FileFsAttributeInformation` handler does not include the `FILE_SUPPORTS_OPEN_BY_FILE_ID` flag (`0x01000000`) in the filesystem attribute flags for volumes reported as NTFS. On real Windows (NTFS), `GetVolumeInformationW()` / `GetVolumeInformationByHandleW()` returns this flag. It has been present on NTFS since Windows Vista. ## Impact on MSYS2 The MSYS2/Cygwin runtime checks the filesystem flags at mount time to decide whether to enable POSIX rename semantics. The relevant Cygwin code path is: 1. `mount_info::init_usr_pathconv()` queries `FileFsAttributeInformation` for each mount point. 2. The flags are stored in `fs_info::flags_`. 3. When `rename()` is called, Cygwin checks whether to use `FileRenameInformationEx` with `FILE_RENAME_POSIX_SEMANTICS`. 4. The decision requires **all three** conditions: - `wincap.has_posix_rename_semantics()` is true (Windows 10 1709+) - The filesystem type is NTFS - The filesystem flags include `FILE_SUPPORTS_OPEN_BY_FILE_ID` Without `FILE_SUPPORTS_OPEN_BY_FILE_ID`, Cygwin falls back to legacy rename behavior using `FileRenameInformation` (info class 10) with only `FILE_RENAME_REPLACE_IF_EXISTS`. This legacy path returns `STATUS_ACCESS_DENIED` when the destination file is held open by another process, even if the handle was opened with `FILE_SHARE_DELETE`. This directly causes the `pacman-key --populate` failure documented in the `posix-rename-semantics` bug: GnuPG's `rename(pubring.gpg, pubring.gpg~)` fails because `gpg-agent` holds `pubring.gpg~` open from the previous signing operation. **Note:** Even with `FILE_RENAME_POSIX_SEMANTICS` support implemented in the Wine server (see the `posix-rename-semantics` bug), MSYS2 will never use it unless this flag is also reported, because the Cygwin runtime gates the feature on the filesystem attribute check. ## Reproducer ``` x86_64-w64-mingw32-gcc -o reproducer.exe reproducer.c wine reproducer.exe ``` ### Expected output (Windows 10+, NTFS) ``` C:\: fs=NTFS flags=0x03e706ff C:\: FILE_SUPPORTS_OPEN_BY_FILE_ID: YES (PASS) Z:\: fs=NTFS flags=0x03e706ff Z:\: FILE_SUPPORTS_OPEN_BY_FILE_ID: YES (PASS) PASS ``` (Exact flag values vary by Windows version and filesystem features.) ### Actual output (Wine 10.0) ``` C:\: fs=NTFS flags=0x0000000a C:\: FILE_SUPPORTS_OPEN_BY_FILE_ID: NO (FAIL) Z:\: fs=NTFS flags=0x0000000a Z:\: FILE_SUPPORTS_OPEN_BY_FILE_ID: NO (FAIL) FAIL ``` ## Analysis Wine reports NTFS filesystem attributes in two locations: ### `dlls/ntdll/unix/file.c` — `NtQueryVolumeInformationFile` The `FileFsAttributeInformation` handler's default (NTFS) case returns: ```c info->FileSystemAttributes = FILE_CASE_PRESERVED_NAMES | FILE_PERSISTENT_ACLS; ``` This is `0x00000002 | 0x00000008` = `0x0000000a`. ### `dlls/mountmgr.sys/device.c` — `harddisk_query_volume` The `FileFsAttributeInformation` handler's default (NTFS) case returns: ```c info->FileSystemAttributes = FILE_CASE_PRESERVED_NAMES | FILE_PERSISTENT_ACLS | FILE_SUPPORTS_REPARSE_POINTS; ``` This is `0x00000002 | 0x00000008 | 0x00000080` = `0x0000008a`. Neither includes `FILE_SUPPORTS_OPEN_BY_FILE_ID` (`0x01000000`). Real Windows 10 NTFS reports a rich set of flags including at minimum: `FILE_CASE_PRESERVED_NAMES`, `FILE_PERSISTENT_ACLS`, `FILE_SUPPORTS_REPARSE_POINTS`, `FILE_SUPPORTS_OPEN_BY_FILE_ID`, and many others. The minimal fix is to add `FILE_SUPPORTS_OPEN_BY_FILE_ID` to both default NTFS cases. ## Fix The fix is straightforward — add `FILE_SUPPORTS_OPEN_BY_FILE_ID` to the NTFS default filesystem flags in both locations: - `dlls/ntdll/unix/file.c`: `NtQueryVolumeInformationFile`, `FileFsAttributeInformation` default case - `dlls/mountmgr.sys/device.c`: `harddisk_query_volume`, `FileFsAttributeInformation` default case The constant is already defined in `include/winnt.h`. Commit on branch `msys2-hacks-23`: - `578e06f7b57` `ntdll, mountmgr: Report FILE_SUPPORTS_OPEN_BY_FILE_ID for NTFS volumes.` ### After fix ``` C:\: fs=NTFS flags=0x0100008a C:\: FILE_SUPPORTS_OPEN_BY_FILE_ID: YES (PASS) Z:\: fs=NTFS flags=0x0100000a Z:\: FILE_SUPPORTS_OPEN_BY_FILE_ID: YES (PASS) PASS ``` ## Verified against - Wine 10.0 (nixpkgs upstream): **bug present** (`flags=0x0000000a`) - Wine 11.4 (msys2-hacks-23, commit `578e06f7b57`): **fixed** (`flags=0x0100000a`) - Real Windows 10 build 22631: flag present (`flags=0x03e706ff`) ## Environment - Wine: 10.0 (nixpkgs), 11.4 (msys2-hacks-23) - Windows: 10.0.22631 (reference) - MSYS2 runtime: 3.6.9-1 - Host: Linux x86_64 (NixOS) -- 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.

1 5

[Bug 59519] New: ole32: OLE clipboard caches stale window handle after STA thread terminates, breaking subsequent OleSetClipboard calls
by WineHQ Bugzilla May 14, 2026

May 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=59519 Bug ID: 59519 Summary: ole32: OLE clipboard caches stale window handle after STA thread terminates, breaking subsequent OleSetClipboard calls Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ole32 Assignee: wine-bugs(a)list.winehq.org Reporter: ayourk(a)gmail.com Distribution: --- Created attachment 80543 --> http://bugs.winehq.org/attachment.cgi?id=80543 reproducer source This bug is really starting to bug me ;) so I figured it was time to report it and squash it! I know that in REAL Windows, this works fine, but as you can test from the attached sample app, the clipboard copy only really works once before the application has to be restarted for it to work again. OleSetClipboard fails with CLIPBRD_E_CANT_OPEN (0x800401D0) on the second and all subsequent calls when each call is made from a new STA thread and the main thread has OLE initialized. This pattern is used by .NET WinForms applications. Clipboard.SetText() internally spawns a new STA thread, calls OleSetClipboard, then exits the thread. The main thread keeps OLE initialized (.NET runtime), so OLE_moduleLockCount never drops to 0 and clipbrd_uninitialize() never runs on the copy threads. The cached clipboard window HWND from the first (now-dead) thread is never cleared. This is deterministic, not a race condition. 100% reproducible on Wine 9.0 through 11.0. I even tested it on the latest development branch. The buggy caching pattern has been present since the OLE clipboard was first implemented (commit 557ff419bea, July 18, 1999), so this affects every Wine version ever released. It went unnoticed because the trigger pattern (main thread keeps OLE alive + new STA threads for each clipboard operation) is specific to .NET WinForms applications. Affected application: Space Engineers (Steam App ID 244850) — Ctrl+C works once, then freezes for ~1 second on every subsequent Ctrl+C. The clipboard never updates past the first copy. This is also reported at https://github.com/ValveSoftware/Proton/issues/1792 STEPS TO REPRODUCE ================== Prerequisites: Main thread has OLE initialized (OleInitialize), as in any .NET application. 1. Spawn STA Thread A: OleInitialize(NULL) -> OleSetClipboard(NULL) -> OleSetClipboard(data1) -> OleFlushClipboard() -> OleUninitialize() -> thread exits Wait for Thread A to complete. 2. Paste: OpenClipboard(NULL) -> GetClipboardData(CF_TEXT) -> "first" Result: correct. 3. Spawn STA Thread B: OleInitialize(NULL) -> OleSetClipboard(NULL) Result: returns 0x800401D0 (CLIPBRD_E_CANT_OPEN) All 10 retries fail with the same error. 4. Paste: GetClipboardData(CF_TEXT) -> still "first" Expected: "second" 5. All subsequent copy attempts from new threads fail the same way. EXPECTED BEHAVIOR (Windows) =========================== Each copy succeeds immediately. After step 3, the clipboard contains "second". Tested on Windows 7, 10, and 11 -- all succeed. ACTUAL BEHAVIOR (Wine 9.0 through 11.0) ======================================== First copy succeeds. All subsequent copies fail with CLIPBRD_E_CANT_OPEN. The clipboard permanently retains the first copied text. Each failed copy takes ~1 second (10 retries x 100ms). ROOT CAUSE ========== In dlls/ole32/clipboard.c, get_clipbrd_window() caches a single HWND per process: static inline HRESULT get_clipbrd_window(ole_clipbrd *clipbrd, HWND *wnd) { if ( !clipbrd->window ) clipbrd->window = create_clipbrd_window(); *wnd = clipbrd->window; return *wnd ? S_OK : E_FAIL; } When the STA thread that created this window terminates, the window is destroyed but the stale HWND remains cached. clipbrd_uninitialize() (which clears it) only runs when OLE_moduleLockCount drops to 0, which never happens in a .NET app because the main thread keeps OLE alive. PROPOSED FIX ============ Add an IsWindow() check to get_clipbrd_window(): if ( clipbrd->window && !IsWindow(clipbrd->window) ) clipbrd->window = NULL; This detects the stale handle and forces creation of a fresh window on the current thread. Patch is attached. REPRODUCER ========== A standalone GUI test app is attached (clipboard_test.c + .exe). It has two modes: Mode A (Bug): Replicates the exact .NET OLE clipboard path. - Main thread calls OleInitialize (simulates .NET environment) - Each copy spawns a new STA thread: OleInitialize -> OleSetClipboard(NULL) -> OleSetClipboard(data) -> OleFlushClipboard -> OleUninitialize -> exit - 10-retry loop with 100ms delays (matches .NET Clipboard.SetText exactly) - Three copy/paste cycles with "first", "second", "third" - Copy 1 succeeds; Copy 2 and 3 fail with 0x800401D0 Mode B (Fix): Same OLE operations but manages the clipboard window lifetime correctly, demonstrating the fix works. - All three copies succeed. Build: x86_64-w64-mingw32-gcc -o clipboard_test.exe clipboard_test.c \ -lgdi32 -lole32 -luuid -mwindows Run: wine clipboard_test.exe Log output (clipboard_test.log) is attached showing the failure. -- 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.

1 4

[Bug 59303] New: FlatOut 2 has not yet implemented feature: Input mask 0xf reads components not written in output mask 0x3.
by WineHQ Bugzilla May 14, 2026

May 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=59303 Bug ID: 59303 Summary: FlatOut 2 has not yet implemented feature: Input mask 0xf reads components not written in output mask 0x3. Product: vkd3d Version: 1.18 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: hlsl Assignee: wine-bugs(a)list.winehq.org Reporter: andrey.goosev(a)gmail.com Distribution: --- 083c:fixme:d3d_shader:shader_spirv_compile_shader Shader log: 083c:fixme:d3d_shader:shader_spirv_compile_shader <anonymous>: E9000: Aborting due to not yet implemented feature: Input mask 0xf reads components not written in output mask 0x3. 083c:fixme:d3d_shader:shader_spirv_compile_shader 083c:err:d3d_shader:shader_spirv_compile_shader Failed to compile shader, ret -5. 083c:err:d3d:wined3d_context_vk_apply_draw_state No pipeline layout set. 083c:err:d3d:adapter_vk_draw_primitive Failed to apply draw state. vkd3d-1.18-211-gd9210a62 -- 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.

1 3

[Bug 50182] New: Hotline Miami 2 GOG version not launch after install.
by WineHQ Bugzilla May 14, 2026

May 14, 2026

https://bugs.winehq.org/show_bug.cgi?id=50182 Bug ID: 50182 Summary: Hotline Miami 2 GOG version not launch after install. Product: Wine Version: 5.21 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: pamungkassendy(a)gmail.com Distribution: --- Created attachment 68700 --> https://bugs.winehq.org/attachment.cgi?id=68700 Hotline Miami 2 GOG Version Game Didn't launch and instead give a crasth report -- 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.

2 3

[Bug 53914] New: Pivot Animator crashes during install
by WineHQ Bugzilla May 14, 2026

May 14, 2026

https://bugs.winehq.org/show_bug.cgi?id=53914 Bug ID: 53914 Summary: Pivot Animator crashes during install Product: Wine Version: 7.20 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: dark.shadow4(a)web.de Distribution: --- Created attachment 73467 --> https://bugs.winehq.org/attachment.cgi?id=73467 Log Download at https://www.pivotanimator.net/DownloadV5.php Can't archive because it downloads a different version then? Very weird... -- 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.

2 5

[Bug 59750] New: Game with midi audio will play incorrectly. (test with Poppo)
by WineHQ Bugzilla May 14, 2026

May 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=59750 Bug ID: 59750 Summary: Game with midi audio will play incorrectly. (test with Poppo) Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: l12436.tw(a)gmail.com Distribution: --- In some game, the BGM will play incorrect in wine, but it play normally in windows -- 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.

1 6

[Bug 42898] New: Listbox keyboard input
by wine-bugs＠winehq.org May 14, 2026

May 14, 2026

https://bugs.winehq.org/show_bug.cgi?id=42898 Bug ID: 42898 Summary: Listbox keyboard input Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: janwinehq(a)gmail.com Distribution: --- A listbox widget in Wine does not react the same way to keyboard input as in Windows. In Windows, you can type the first characters of a word and the cursor will jump to the first item matching *all* the characters you typed. This allows you to drill down quickly to the item you want. In Wine, when you start typing it only considers the *last* character you typed when looking for a match. On listboxes where you have lots of items starting with the same character, this can make it problematic to drill down to the correct item. This may be better explained with a simple example. Suppose you have a listbox with the following items, sorted alphabetically: * AMBER * BLUE * BROWN * GREEN * ORANGE * RED * YELLOW Windows behavior: * if you type "B", it will drill down to "BLUE" * if you type "BR", it will drill down to "BROWN" * if you type "BRO", it will drill down to "BROWN" Wine behavior: * if you type "B", it will drill down to "BLUE" * if you type "BR", it will drill down to "RED" * if you type "BRO", it will drill down to "ORANGE" -- 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.

3 11