git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Taylor Blau <me@ttaylorr.com>
To: Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>
Cc: Patrick Steinhardt <ps@pks.im>,
	git@vger.kernel.org,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH 2/3] compat/mingw: allow deletion of most opened files
Date: Wed, 23 Oct 2024 13:30:24 -0400	[thread overview]
Message-ID: <ZxkysCb/d3+PJjW4@nand.local> (raw)
In-Reply-To: <bc829d84-6696-4e16-9687-8ba611af29ff@app.fastmail.com>

On Wed, Oct 23, 2024 at 06:17:15PM +0200, Kristoffer Haugsbakk wrote:
> On Wed, Oct 23, 2024, at 17:05, Patrick Steinhardt wrote:
> > On Windows, we emulate open(3p) via `mingw_open()`. This function
> > implements handling of some platform- specific quirks that are required
>
> s/platform- specific/platform-specific/
>
> Linewrapping artifact?

Looks like it. Thanks for spotting.

> > to make it behave as closely as possible like open(3p) would, but for
> > most cases we just call the Windows-specific `_wopen()` function.
> >
> > This function has a major downside though: it does not allow us to
> > specify the sharing mode. While there is `_wsopen()` that allows us to
> > pass sharing flags, those sharing flags are not the same `FILE_SHARE_*`
> > flags as `CreateFileW()` accepts. Instead, `_wsopen()` only allows
> > concurrent read- and write-access, but does not allow for concurrent
> > deletions. Unfortunately though, we have to allow concurrent deletions
> > if we want to have POSIX-style atomic renames on top of an existing file
> > that has open file handles.
> >
> > Implement a new function that emulates open(3p) for existing files via
> > `CreateFileW()` such that we can set the required sharing flags.
> >
> > While we have the same issue when calling open(3p) with `O_CREAT`,
>
> s/O_CREAT/O_CREATE/ ?

No, O_CREAT is the flag name.

> > +	};
> > +	HANDLE handle;
> > +	int access;
> > +	int fd;
> > +
> > +	/* We only support basic flags. */
> > +	if (oflags & ~(O_ACCMODE | O_NOINHERIT))
> > +		return errno = ENOSYS, -1;
>
> This use of the comma operator is maybe an idiom to save space and avoid
> a brace around the `if`?  This pattern is already in use in
> `mingw_open_append`.  I see in `mingw.h` that it uses:
>
> ```
> static inline int symlink(const char *oldpath UNUSED, const char *newpath UNUSED)
> { errno = ENOSYS; return -1; }
> ```
>

Yeah. What Patrick wrote here is not technically wrong, but I would not
consider it in the style of the rest of the project. Perhaps
compat/mingw-stuff is a bit of a wild west, but I think it would be
match the rest of the project's conventions here.

I actually think from grepping around that mingw_open_append is the only
other function in the tree that uses the "return errno = XXX, -1;"
trick. It might be nice to keep it that way, and/or rewrite that portion
like so:

--- 8< ---
diff --git a/compat/mingw.c b/compat/mingw.c
index df78f61f7f..c36147549a 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -494,8 +494,10 @@ static int mingw_open_append(wchar_t const *wfilename, int oflags, ...)
 	DWORD create = (oflags & O_CREAT) ? OPEN_ALWAYS : OPEN_EXISTING;

 	/* only these flags are supported */
-	if ((oflags & ~O_CREAT) != (O_WRONLY | O_APPEND))
-		return errno = ENOSYS, -1;
+	if ((oflags & ~O_CREAT) != (O_WRONLY | O_APPEND)) {
+		errno = ENOSYS;
+		return -1;
+	}

 	/*
 	 * FILE_SHARE_WRITE is required to permit child processes
--- >8 ---

Thanks,
Taylor

  reply	other threads:[~2024-10-23 17:30 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-23 15:04 [PATCH 0/3] compat/mingw: implement POSIX-style atomic renames Patrick Steinhardt
2024-10-23 15:04 ` [PATCH 1/3] compat/mingw: share file handles created via `CreateFileW()` Patrick Steinhardt
2024-10-23 16:18   ` Kristoffer Haugsbakk
2024-10-23 17:25     ` Taylor Blau
2024-10-23 17:23   ` Taylor Blau
2024-10-23 17:25     ` Taylor Blau
2024-10-24  6:30     ` Patrick Steinhardt
2024-10-27 13:14     ` Johannes Sixt
2024-10-27 23:46       ` Taylor Blau
2024-10-23 15:05 ` [PATCH 2/3] compat/mingw: allow deletion of most opened files Patrick Steinhardt
2024-10-23 16:17   ` Kristoffer Haugsbakk
2024-10-23 17:30     ` Taylor Blau [this message]
2024-10-24  6:30     ` Patrick Steinhardt
2024-10-23 18:07   ` Taylor Blau
2024-10-23 15:05 ` [PATCH 3/3] compat/mingw: support POSIX semantics for atomic renames Patrick Steinhardt
2024-10-23 16:19   ` Kristoffer Haugsbakk
2024-10-24  6:30     ` Patrick Steinhardt
2024-10-24  7:18       ` Kristoffer Haugsbakk
2024-10-24  7:20         ` Patrick Steinhardt
2024-10-23 18:30   ` Taylor Blau
2024-10-23 15:36 ` [PATCH 0/3] compat/mingw: implement POSIX-style " Taylor Blau
2024-10-24 11:46 ` [PATCH v2 " Patrick Steinhardt
2024-10-24 11:46   ` [PATCH v2 1/3] compat/mingw: share file handles created via `CreateFileW()` Patrick Steinhardt
2024-10-24 11:46   ` [PATCH v2 2/3] compat/mingw: allow deletion of most opened files Patrick Steinhardt
2024-10-27 13:17     ` Johannes Sixt
2024-10-27 15:38       ` Patrick Steinhardt
2024-10-27 23:48         ` Taylor Blau
2024-10-27 23:51           ` Taylor Blau
2024-10-24 11:46   ` [PATCH v2 3/3] compat/mingw: support POSIX semantics for atomic renames Patrick Steinhardt
2024-10-27 13:23     ` Johannes Sixt
2024-10-27 15:38       ` Patrick Steinhardt
2024-10-27 16:31         ` Johannes Sixt
2024-10-27 17:27           ` Patrick Steinhardt
2024-10-27 21:36             ` Johannes Sixt
2024-10-27 23:50               ` Taylor Blau
2024-10-24 16:47   ` [PATCH v2 0/3] compat/mingw: implement POSIX-style " Taylor Blau
2024-10-27 13:27   ` Johannes Sixt
2024-10-27 15:39 ` [PATCH v3 " Patrick Steinhardt
2024-10-27 15:39   ` [PATCH v3 1/3] compat/mingw: share file handles created via `CreateFileW()` Patrick Steinhardt
2024-10-27 15:39   ` [PATCH v3 2/3] compat/mingw: allow deletion of most opened files Patrick Steinhardt
2024-10-27 15:39   ` [PATCH v3 3/3] compat/mingw: support POSIX semantics for atomic renames Patrick Steinhardt
2024-11-06  3:54   ` [PATCH v3 0/3] compat/mingw: implement POSIX-style " Junio C Hamano
2024-11-06  6:44     ` Johannes Sixt
2024-11-06 12:09       ` Junio C Hamano

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=ZxkysCb/d3+PJjW4@nand.local \
    --to=me@ttaylorr.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=kristofferhaugsbakk@fastmail.com \
    --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 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).