Hi folks, I'm wanting to resurrect this branch and I rebased it with a tightening of test expectations for `FILE_RENAME_POSIX_SEMANTICS`. This week I have been doing some testing of the MSYS2 pacman, and I now have proof that these patches are necessary: The MSYS2/Cygwin runtime (3.x) uses `FileRenameInformationEx` with `FILE_RENAME_POSIX_SEMANTICS` to implement POSIX `rename()` semantics. This is the primary rename path on local NTFS filesystems when running on Windows 10 1709+. When Wine returns `STATUS_ACCESS_DENIED`, the Cygwin `rename()` call fails with `EACCES` (errno 13). This breaks GnuPG's legacy keyring update mechanism used by `pacman-key --populate`: 1. `gpg-agent` opens `pubring.gpg` for reading and holds the handle 2. `gpg --lsign-key` modifies the keyring: - Writes updated keyring to `pubring.gpg.tmp` - `rename(pubring.gpg, pubring.gpg~)` — backup old keyring - `rename(pubring.gpg.tmp, pubring.gpg)` — install new keyring 3. After step 2 succeeds once, `pubring.gpg~` is the file the agent has open (via its stale handle) 4. On the next `gpg --lsign-key`, the backup rename tries to replace `pubring.gpg~` which has an open handle from the agent 5. Under Wine, this fails with `Permission denied` The result is that every other `gpg --lsign-key` invocation fails during `pacman-key --populate`, preventing MSYS2 package signature verification from being set up. **Note:** This only affects the legacy `pubring.gpg` keyring format. The modern `pubring.kbx` (keybox) format uses a different update mechanism that is not affected. The legacy format is used because `pacman-key --init` pre-creates an empty `pubring.gpg` file, which forces GnuPG to use the legacy format. @zfigura could we give this patch-set a second chance? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4457#note_139022