[Bug 59711] New: unlock_fd: UnlockFile returns ERROR_LOCK_VIOLATION (33) instead of ERROR_NOT_LOCKED (158) when no matching lock is held
http://bugs.winehq.org/show_bug.cgi?id=59711 Bug ID: 59711 Summary: unlock_fd: UnlockFile returns ERROR_LOCK_VIOLATION (33) instead of ERROR_NOT_LOCKED (158) when no matching lock is held Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: ntdll Assignee: wine-bugs@list.winehq.org Reporter: bugzilla-wine@accounts.zanie.blue Distribution: --- Calling `UnlockFile` (or `NtUnlockFile`) for a region that the handle does not currently have a lock on returns `ERROR_LOCK_VIOLATION` (33) under Wine. It should return `ERROR_NOT_LOCKED` (158) instead. This breaks Rust's `std::fs::File::unlock`, which deliberately calls `UnlockFile` twice on every release (to handle the documented case of a handle holding both an exclusive and a shared lock on the same region), and explicitly tolerates `ERROR_NOT_LOCKED` on the second call but propagates any other error [1]. The result is a spurious "Lock violation" error reported by Rust programs that use `File::unlock` under Wine. I encountered this downstream while adding a Wine integration test in uv [2]. In `server/fd.c`, `unlock_fd()` calls `set_error(STATUS_FILE_LOCK_CONFLICT)` when no lock with the exact (start, end) is found on the handle [3]. Per `dlls/ntdll/error.h` that status maps to `ERROR_LOCK_VIOLATION` (33) [4], whereas the semantically correct status for "no such lock" is `STATUS_RANGE_NOT_LOCKED`, which maps to `ERROR_NOT_LOCKED` (158) [5, 6]. [1] https://github.com/rust-lang/rust/blob/f53b654a8882fd5fc036c4ca7a4ff41ce3249... [2] https://github.com/astral-sh/uv [3] https://gitlab.winehq.org/wine/wine/-/blob/master/server/fd.c#L1566-1581 [4] https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/ntdll/error.h#L449 [5] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1... [6] https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/ntdll/error.h#L491 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59711 --- Comment #1 from Zanie Blue <bugzilla-wine@accounts.zanie.blue> --- Note I reproduced this on Wine 9 in CI, but the issue appears to be present on the master branch on GitLab. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59711 Alexandre Julliard <julliard@winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |93939c065914ba622daa9f06c1f | |c4544eab1a72e Status|UNCONFIRMED |RESOLVED --- Comment #2 from Alexandre Julliard <julliard@winehq.org> --- Thanks for catching this, fixed by 93939c065914ba622daa9f06c1fc4544eab1a72e. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59711 Alexandre Julliard <julliard@winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #3 from Alexandre Julliard <julliard@winehq.org> --- Closing bugs fixed in 11.12. -- 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.
participants (1)
-
WineHQ Bugzilla