From: Patrick Steinhardt <ps@pks.im>
To: Johannes Sixt <j6t@kdbg.org>
Cc: Johannes Schindelin <johannes.schindelin@gmx.de>,
Taylor Blau <me@ttaylorr.com>,
Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH v2 2/3] compat/mingw: allow deletion of most opened files
Date: Sun, 27 Oct 2024 16:38:50 +0100 [thread overview]
Message-ID: <Zx5eipv_Un3x1j-4@pks.im> (raw)
In-Reply-To: <a769d5a6-0d0f-4df4-b581-539d00aacbc9@kdbg.org>
On Sun, Oct 27, 2024 at 02:17:36PM +0100, Johannes Sixt wrote:
> Am 24.10.24 um 13:46 schrieb Patrick Steinhardt:
> > diff --git a/compat/mingw.c b/compat/mingw.c
> > index e326c6fcd2d..6c75fe36b15 100644
> > --- a/compat/mingw.c
> > +++ b/compat/mingw.c
> > @@ -532,6 +532,62 @@ static int mingw_open_append(wchar_t const *wfilename, int oflags, ...)
> > return fd;
> > }
> >
> > +/*
> > + * Ideally, we'd use `_wopen()` to implement this functionality so that we
> > + * don't have to reimplement it, but unfortunately we do not have tight control
> > + * over the share mode there. And while `_wsopen()` and friends exist that give
> > + * us _some_ control over the share mode, this family of functions doesn't give
> > + * us the ability to enable FILE_SHARE_DELETE, either. But this is a strict
> > + * requirement for us though so that we can unlink or rename over files that
> > + * are held open by another process.
> > + *
> > + * We are thus forced to implement our own emulation of `open()`. To make our
> > + * life simpler we only implement basic support for this, namely opening
> > + * existing files for reading and/or writing. This means that newly created
> > + * files won't have their sharing mode set up correctly, but for now I couldn't
> > + * find any case where this matters. We may have to revisit that in the future
> > + * though based on our needs.
> > + */
> > +static int mingw_open_existing(const wchar_t *filename, int oflags, ...)
> > +{
> > + SECURITY_ATTRIBUTES security_attributes = {
> > + .nLength = sizeof(security_attributes),
> > + .bInheritHandle = !(oflags & O_NOINHERIT),
> > + };
> > + HANDLE handle;
> > + int access;
>
> I would have made this variable DWORD or unsigned instead of plain int,
> because it receives a bit pattern and would match the parameter type of
> CreateFileW() better; but no big deal.
I have to reroll this series anyway, so I'll just fix this while at it.
> > + int fd;
> > +
> > + /* We only support basic flags. */
> > + if (oflags & ~(O_ACCMODE | O_NOINHERIT)) {
> > + errno = ENOSYS;
> > + return -1;
> > + }
> > +
> > + if (oflags & O_RDWR)
> > + access = GENERIC_READ | GENERIC_WRITE;
> > + else if (oflags & O_WRONLY)
> > + access = GENERIC_WRITE;
> > + else
> > + access = GENERIC_READ;
>
> O_RDWR, O_WRONLY and O_RDONLY are not flags, but values occupying two
> bits of oflags. This must be:
>
> if ((oflags & O_ACCMODE) == O_RDWR)
> access = GENERIC_READ | GENERIC_WRITE;
> else if ((oflags & O_ACCMODE) == O_WRONLY)
> access = GENERIC_WRITE;
> else
> access = GENERIC_READ;
>
> or similar.
Ah, that makes sense indeed. Will fix.
> > +
> > + handle = CreateFileW(filename, access,
> > + FILE_SHARE_WRITE | FILE_SHARE_READ | FILE_SHARE_DELETE,
> > + &security_attributes, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
> > + if (handle == INVALID_HANDLE_VALUE) {
> > + DWORD err = GetLastError();
> > + if (err == ERROR_INVALID_PARAMETER)
> > + err = ERROR_PATH_NOT_FOUND;
>
> First I wondered what this is about, but then noticed that it is just
> copied from the mingw_open_append() implementation catering to some
> bogus network filesystems. Good.
I'll add a comment.
Patrick
next prev parent reply other threads:[~2024-10-27 15:38 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
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 [this message]
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=Zx5eipv_Un3x1j-4@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=j6t@kdbg.org \
--cc=johannes.schindelin@gmx.de \
--cc=kristofferhaugsbakk@fastmail.com \
--cc=me@ttaylorr.com \
/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).