Re: unlink errors under windows in git pack-refs

From: Patrick Steinhardt <ps@pks.im>
Date: Jan 24, 2025, 06:36 UTC
Message-ID: <Z5M08DQCZ_43EIbm@pks.im>
In-Reply-To: <d7fd0b1c-98fe-4cc3-b657-c2c3d0bc5c47@t-online.de>

On Wed, Jan 22, 2025 at 08:01:31PM +0100, Christian Reich wrote:

Show 19 quoted lines

> What happened instead? (Actual behavior)
> 
> git tries to unlink the reftable-files, but jgit hold windows-system lock,
> so the file can't be unlinked.
> An answers 'n' for retry causes more asks. After the third try git give up.
> 
> Unlink of file 'C:/temp/jgittest/jgit/.git/reftable/0x000000000002-0x000000000004-50486d0e.ref'
> failed. Should I try again? (y/n) n
> Unlink of file 'C:/temp/jgittest/jgit/.git/reftable/0x000000000002-0x000000000004-50486d0e.ref'
> failed. Should I try again? (y/n) n
> Unlink of file 'C:/temp/jgittest/jgit/.git/reftable/0x000000000002-0x000000000004-50486d0e.ref'
> failed. Should I try again? (y/n) n
> 
> 
> What's different between what you expected and what actually happened?
> 
> I would expect, that git tries to unlink the files. But if this fails git
> should ignore this and try to delete the files next time on pack-files. Its
> documented in https://git-scm.com/docs/reftable

Yeah, very true, it is expected that unlinking old reftables may fail, and this should be totally benign indeed. In fact, none of the callsites of unlink(3p) even check its return value and we just continue to run witih stale files.

The question comes from `mingw_unlink()`, which we use on Windows platforms:

	while (ret == -1 && is_file_in_use_error(GetLastError()) &&
	       ask_yes_no_if_possible("Unlink of file '%s' failed. "
			"Should I try again?", pathname))
	       ret = _wunlink(wpathname);

As you can see, the loop should immediately exit when you answer 'n', and I assume that this even happens. So where do the other asks come from? One such location is in `reftable_be_pack_refs()`, which calls `reftable_stack_clean()`. This function will try to prune any old tables which aren't referenced anymore. The other callsite comes from reloading the stack, where we again try to unlink now-unreferenced tables. All of these calls are benign.

So the problem is that we use the EBUSY-handling in `mingw_unlink()` in the first place. I'll send a patch in a bit to address this issue.

Thanks for the report!

Patrick