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

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