On Mon, Feb 24, 2025 at 4:53 AM Patrick Steinhardt <ps@xxxxxx> 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
