]> git.ipfire.org Git - thirdparty/git.git/commit
object-file: retry linking file into place when occluding file vanishes
authorPatrick Steinhardt <ps@pks.im>
Mon, 6 Jan 2025 09:24:27 +0000 (10:24 +0100)
committerJunio C Hamano <gitster@pobox.com>
Mon, 6 Jan 2025 15:57:17 +0000 (07:57 -0800)
commitd7fcbe2c56468ac780c689b02c6a9e056ce39c12
tree3dbf3ff915442b3fad248a2ff437a0adf3b6580c
parentcfae50e40eb72d6116ad56c616b3322474df4a75
object-file: retry linking file into place when occluding file vanishes

Prior to 0ad3d65652 (object-file: fix race in object collision check,
2024-12-30), callers could expect that a successful return from
`finalize_object_file()` means that either the file was moved into
place, or the identical bytes were already present. If neither of those
happens, we'd return an error.

Since that commit, if the destination file disappears between our
link(3p) call and the collision check, we'd return success without
actually checking the contents, and without retrying the link. This
solves the common case that the files were indeed the same, but it means
that we may corrupt the repository if they weren't (this implies a hash
collision, but the whole point of this function is protecting against
hash collisions).

We can't be pessimistic and assume they're different; that hurts the
common case that the mentioned commit was trying to fix. But after
seeing that the destination file went away, we can retry linking again.
Adapt the code to do so when we see that the destination file has racily
vanished. This should generally succeed as we have just observed that
the destination file does not exist anymore, except in the very unlikely
event that it gets recreated by another concurrent process again.

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