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
next prev parent 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).