Re: [PATCH] reftable: ignore file-in-use errors when unlink(3p) fails on Windows

From: Johannes Sixt <j6t@kdbg.org>
Date: Jan 28, 2025, 06:52 UTC
Message-ID: <b9b548e0-e42e-4854-92f2-337a26f692ac@kdbg.org>
In-Reply-To: <Z5c6VlsdNXwYkUsv@pks.im>

Am 27.01.25 um 08:48 schrieb Patrick Steinhardt:

Show 9 quoted lines

> 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