All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org,  Johannes Sixt <j6t@kdbg.org>,
	 Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH 1/2] compat/mingw: handle O_CLOEXEC in `mingw_open_existing()`
Date: Thu, 13 Mar 2025 10:52:17 -0700	[thread overview]
Message-ID: <xmqqo6y4om26.fsf@gitster.g> (raw)
In-Reply-To: <20250313-b4-pks-mingw-lockfile-flake-v1-1-bc5d3e70f516@pks.im> (Patrick Steinhardt's message of "Thu, 13 Mar 2025 15:17:43 +0100")

Patrick Steinhardt <ps@pks.im> writes:

> 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.

This one looks quite sensible and straight-forward even to a
non-Windows person like me.

> 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;

  reply	other threads:[~2025-03-13 17:53 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 ` [PATCH 1/2] compat/mingw: handle O_CLOEXEC in `mingw_open_existing()` Patrick Steinhardt
2025-03-13 17:52   ` Junio C Hamano [this message]
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=xmqqo6y4om26.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=j6t@kdbg.org \
    --cc=ps@pks.im \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.