On Wed May 13 22:19:10 2026 +0000, Alexandre Julliard wrote:
I'm not convinced that msys2 is a valid use case, but anyway... That `set_fd_name` function could use some helpers, but `get_inode_open_sharing` is not a very good helper, there's very little in common between the different use cases. Hi @julliard . Thank you for having a look.
That `set_fd_name` function could use some helpers, but `get_inode_open_sharing` is not a very good helper, there's very little in common between the different use cases.
Regarding this merge request, I have removed the `get_inode_open_sharing` helper and open-coded it. I agree that the helper was marginal.
That `set_fd_name` function could use some helpers, but `get_inode_open_sharing` is not a very good helper, there's very little in common between the different use cases.
I don't think it's for me to say whether the use case is valid or not. I can only say that there are a fair few people who find value in it. It is the [top FAQ item](https://www.msys2.org/docs/faq/) on the MSYS2 website. The associated [tracking bug in GitHub](https://github.com/msys2/MSYS2-packages/issues/682) has a large number of interested participants. I maintain a long-running patch series, the latest release of which is [`msys2-hacks-23`](https://gitlab.winehq.org/jhol/wine/-/commits/msys2-hacks-23), and I have been working on a multi-year effort to get full support including contributions from multiple developers, particularly from @bernhardu . The primary consumer of these branches is [msys2-docker](https://github.com/msys2/msys2-docker) which packages Wine and MSYS2 inside a docker image. Regarding functionality, our project is nearly complete. My original use case for this is to get a msys2/mingw package-building process fully working in a linux-based CI system. In `msys2-hacks-23`, I have been able, for the first time, to get full end-to-end support for our build process. This includes exentensive use of pacman (with GnuPG), as well as the build and packaging of customized builds of GCC and Binutils. This use case greatly stresses the MSYS2/Wine stack. We also have near-complete support for [msys2-runtime winsup test suite](https://github.com/msys2/msys2-runtime/tree/msys2-3.6.9/winsup/testsuite), with only one known remaining Wine bug [#33576](https://bugs.winehq.org/show_bug.cgi?id=33576) preventing a clean run. All this to say, that in my opinion these changes *do* have value, and that the requirements are bounded, and that we not far from having full support. The remaining change-set that I have are: * This one. * [!8030: wineserver: Allow NtOpenFile with read-only files.](https://gitlab.winehq.org/wine/wine/-/merge_requests/8030) * [!10866: Report FILE_SUPPORTS_OPEN_BY_FILE_ID](https://gitlab.winehq.org/wine/wine/-/merge_requests/10866) And from @bernhardu are: * [!10044: server: Clear connection failure events in IOCTL_AFD_WINE_CONNECT.](https://gitlab.winehq.org/wine/wine/-/merge_requests/10044) * [patch: ntdll: Add read and write to commited guard pages.](https://gitlab.winehq.org/jhol/wine/-/commit/3ac28dca1710d12dfe290e264c3f57c...) In my opinion, full support for MSYS2 in main-line Wine is within reach. Therefore, if you have a chance to review any of these patches, I would be enormously grateful. Thank you for your time. Please let me know if there is anything I can do to make the process easier. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4457#note_139743