Am 27.01.25 um 08:48 schrieb Patrick Steinhardt: > On Sat, Jan 25, 2025 at 03:28:28PM +0100, Johannes Sixt wrote: >> Am 25.01.25 um 09:32 schrieb Patrick Steinhardt: >> Instead of calling _wunlink() in mingw_unlink, we could CreateFileW() >> with access mode DELETE and flag FILE_FLAG_DELETE_ON_CLOSE, then close >> the file right away. That would apply semantics that is similar, but not >> quite, POSIX at least among the files that we open ourselves. > > Huh. And that works even when the file is still being held open by other > processes? Only if the process cooperates and has opened the file with FILE_SHARE_DELETE. So, in general, no. I think, Cygwin implements unlink() in this manner. > I have a feeling that there's a misunderstanding here, either on my side > or on yours. It's the rest of Git that wants to have POSIX behaviour for > `unlink()`, not the reftable library. Yes and no. Yes, we expect to be able to delete a file that was opened by some *other* Git process (e.g., packfiles during gc), but, no, we do not delete files that have been opened in the current process and are still open. For this reason, I am arguing to remove the interactive part of mingw_unlink() and use the cooperative strategy I mentioned above. That gives us POSIX-like behavior for concurrent Git processes. The interactive question is only useful when the user has control over an uncooperative process that keeps a file open for an extended time and can find that processes, which is either obvious or extremely difficult. As I said, I haven't seen the question since a long, long time now, but I am also the first to admit that my way of using Git is rather narrow. -- Hannes
