From: Patrick Steinhardt <ps@pks.im>
To: git@vger.kernel.org
Cc: Johannes Sixt <j6t@kdbg.org>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: [PATCH 1/2] compat/mingw: handle O_CLOEXEC in `mingw_open_existing()`
Date: Thu, 13 Mar 2025 15:17:43 +0100 [thread overview]
Message-ID: <20250313-b4-pks-mingw-lockfile-flake-v1-1-bc5d3e70f516@pks.im> (raw)
In-Reply-To: <20250313-b4-pks-mingw-lockfile-flake-v1-0-bc5d3e70f516@pks.im>
Our MinGW emulation of the open(3p) syscall uses one of three different
code paths depending on the flags passed by the caller. Ideally, we
would just use `_wopen()` for all of these directly and instead rely on
the Windows SDK to implement the logic for us. But unfortunately, this
interface does not allow us to set the `FILE_SHARING_*` flags, which we
need to have control over to implement POSIX semantics.
One of the code paths is for opening existing files, where we end up
calling `mingw_open_existing()`. While this code path is executed when
the user passes `O_NOINHERIT`, we don't know to handle `O_CLOEXEC` yet,
which causes a couple of code paths that use the flag to not use the
emulation. The consequence is that those code paths do not support POSIX
semantics because we don't know to set the sharing mode correctly.
Supporting `O_CLOEXEC` is quite trivial: we don't have to do anything,
as Windows already closes the file handle by default when exec'ing into
another process. This is further supported by the fact that we indeed
define `O_CLOEXEC` as `O_NOINHERIT` in case the former isn't defined in
"compat/mingw.h".
Adapt the code so that we know to handle `O_CLOEXEC` in case it has a
different definition than `O_NOINHERIT` to improve our POSIX semantics
handling.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
compat/mingw.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index f524c54d06d..101e380c5a3 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -560,7 +560,7 @@ static int mingw_open_existing(const wchar_t *filename, int oflags, ...)
int fd;
/* We only support basic flags. */
- if (oflags & ~(O_ACCMODE | O_NOINHERIT)) {
+ if (oflags & ~(O_ACCMODE | O_NOINHERIT | O_CLOEXEC)) {
errno = ENOSYS;
return -1;
}
@@ -632,7 +632,7 @@ int mingw_open (const char *filename, int oflags, ...)
if ((oflags & O_APPEND) && !is_local_named_pipe_path(filename))
open_fn = mingw_open_append;
- else if (!(oflags & ~(O_ACCMODE | O_NOINHERIT)))
+ else if (!(oflags & ~(O_ACCMODE | O_NOINHERIT | O_CLOEXEC)))
open_fn = mingw_open_existing;
else
open_fn = _wopen;
--
2.49.0.rc2.394.gf6994c5077.dirty
next prev parent reply other threads:[~2025-03-13 14:17 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-13 14:17 [PATCH 0/2] compat/mingw: fix EACCESS when opening files with `O_CREAT | O_EXCL` Patrick Steinhardt
2025-03-13 14:17 ` Patrick Steinhardt [this message]
2025-03-13 17:52 ` [PATCH 1/2] compat/mingw: handle O_CLOEXEC in `mingw_open_existing()` Junio C Hamano
2025-03-13 14:17 ` [PATCH 2/2] compat/mingw: fix EACCESS when opening files with `O_CREAT | O_EXCL` Patrick Steinhardt
2025-03-13 18:02 ` Junio C Hamano
2025-03-16 0:01 ` Johannes Schindelin
2025-03-17 15:16 ` Patrick Steinhardt
2025-03-20 10:37 ` [PATCH v2 0/2] " Patrick Steinhardt
2025-03-20 10:37 ` [PATCH v2 1/2] meson: fix compat sources when compiling with MSVC Patrick Steinhardt
2025-03-20 10:37 ` [PATCH v2 2/2] compat/mingw: fix EACCESS when opening files with `O_CREAT | O_EXCL` Patrick Steinhardt
2025-03-26 12:20 ` Johannes Schindelin
2025-03-28 9:20 ` Patrick Steinhardt
2025-03-28 15:41 ` Johannes Schindelin
2025-03-31 6:57 ` Patrick Steinhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250313-b4-pks-mingw-lockfile-flake-v1-1-bc5d3e70f516@pks.im \
--to=ps@pks.im \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=j6t@kdbg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).