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

[Patrick Steinhardt <ps@pks.im>]

On Tue, Jan 28, 2025 at 07:52:48AM +0100, Johannes Sixt wrote:
> 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:
> > 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.

That would be a much wider change compared to what I'm proposing though.
I don't quite feel comfortable with pushing for such a change as I don't
have enough of a stake in Windows to be able to judge whether it would
be sensible or not.

If Dscho confirms your take I'm happy to do so. But otherwise I'd prefer
to continue with the more limited scope, as I know that the behaviour is
unexpected and unnecessary in the reftable library.

Patrick