Re: Unknown error with concurrent config read/write on Windows

[Allen Li <darkfeline@felesatra.moe>]

On Mon, Feb 24, 2025 at 4:53 AM Patrick Steinhardt <ps@pks.im> wrote:
> I'm not quite sure which version you're referring to here. 28.0 is not a
> version released by either GIt nor Git for Windows. You probably meant
> to refer to v2.48.0?

Yes sorry, I meant v2.48.0

> In any case, it's not entirely surprising that this may still cause
> issues in some code paths. Support for POSIX-style renames requires two
> different bits:
>
>   - The `rename()` implementation needs to know to allow POSIX-style
>     renames even when the target file is currently held open.
>
>   - All code paths that open a file need to be taught to open them with
>     `FILE_SHARE_DELETE`. This flag allows the file to be deleted while
>     the file handle remains open.
>
> The first part has been implemented by the mentioned patch series, and
> some code paths have been adapted to also do the second part. But not
> all code paths do this yet, and those that don't will not be able to use
> atomic renames when the file is open.
>
> One important omission in your context is that fopen(3p) does not yet
> know to set `FILE_SHARE_DELETE`. It uses `_wfopen()` right now, which
> does not set this flag. In the best case we'd convert the code to use
> `_wfsopen()` instead, which allows us to control the sharing mode. But
> unfortunately, it only allows us to control `FILe_SHARE_WRITE` as well
> as `FILE_SHARE_READ`, but not `FILE_SHARE_DELETE`.
>
> So to the best of my knowledge, we'd have to reimplement the function on
> top of `CreateFileW()` so that we can fully control the file sharing
> mode.

Thank you, that makes sense.  We ended up committing to a different
approach which
sidesteps this problem, but I think there's enough context here for
anyone else who
may experience this problem to take a shot at fixing it (perhaps it
will be future me).

> Patrick