]> git.ipfire.org Git - thirdparty/git.git/commit
receive-pack: fix stale packfile locks when dying
authorPatrick Steinhardt <ps@pks.im>
Fri, 10 Mar 2023 06:52:10 +0000 (07:52 +0100)
committerJunio C Hamano <gitster@pobox.com>
Fri, 10 Mar 2023 16:40:13 +0000 (08:40 -0800)
commitc55c30669ced6e08b41b3c921f0da200247c9811
treeb7a3207c326814a760309d9c9a2f9eac8e4e04ec
parent7556e5d737b917d31ac3729b0f5e2391da7e132a
receive-pack: fix stale packfile locks when dying

When accepting a packfile in git-receive-pack(1), we feed that packfile
into git-index-pack(1) to generate the packfile index. As the packfile
would often only contain unreachable objects until the references have
been updated, concurrently running garbage collection might be tempted
to delete the packfile right away and thus cause corruption. To fix
this, we ask git-index-pack(1) to create a `.keep` file before moving
the packfile into place, which is getting deleted again once all of the
reference updates have been processed.

Now in production systems we have observed that those `.keep` files are
sometimes not getting deleted as expected, where the result is that
repositories tend to grow packfiles that are never deleted over time.
This seems to be caused by a race when git-receive-pack(1) is killed
after we have migrated the kept packfile from the quarantine directory
into the main object database. While this race window is typically small
it can be extended for example by installing a `proc-receive` hook.

Fix this race by registering the lockfile as a tempfile so that it will
automatically be removed at exit or when receiving a signal.

Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/receive-pack.c