Am 25.01.25 um 06:41 schrieb Patrick Steinhardt:
> While this logic might be sensible in many callsites throughout Git, it
> is less when used in the reftable library. We only use unlink(3) there
> to delete tables which aren't referenced anymore, and the code is very
> aware of the limitations on Windows. As such, all calls to unlink(3p)
> don't perform any error checking at all and are fine with the call
> failing.
>
> Instead, the library provides the `reftable_stack_clean()` function,
> which Git knows to execute in git-pack-refs(1) after compacting a stack.
> The effect of this function is that all stale tables will eventually get
> deleted once they aren't kept open anymore.
>
> So while we're fine with unlink(3p) failing, the Windows-emulation of
> that function will still perform several sleeps and ultimately end up
> asking the user:
Why don't the changes that your commits ending at 391bceae4350
("compat/mingw: support POSIX semantics for atomic renames", 2024-10-27)
help in this case, too?
Since the reftable layer is aware of the problem, why don't we just fix
it there and instead sweep it under the rug in the compat layer?
-- Hannes
