From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Patrick Steinhardt <ps@pks.im>, git@vger.kernel.org
Subject: Re: [PATCH 2/2] object-file: retry linking file into place when occluding file vanishes
Date: Fri, 03 Jan 2025 12:25:38 -0800 [thread overview]
Message-ID: <xmqqsepzprul.fsf@gitster.g> (raw)
In-Reply-To: <20250103194058.GE3208749@coredump.intra.peff.net> (Jeff King's message of "Fri, 3 Jan 2025 14:40:58 -0500")
Jeff King <peff@peff.net> writes:
> I share Junio's uneasiness with looping forever based on external input
> from the filesystem (even though you _should_ eventually win the race,
> that's not guaranteed, and of course a weird filesystem might confuse
> us).
Yeah, "a weird filesystem" would be a lot more plausible than a
determined and accurate attacker to break it. The only thing they
have to do is to yield EEXIST when failing link() for some other
reason.
> Could we put a stop-gap in it like:
>
> diff --git a/object-file.c b/object-file.c
> index 88432cc9c0..262a2f3df2 100644
> --- a/object-file.c
> +++ b/object-file.c
> @@ -2038,6 +2038,7 @@ int finalize_object_file_flags(const char *tmpfile, const char *filename,
> enum finalize_object_file_flags flags)
> {
> int ret;
> + int retries = 0;
>
> retry:
> ret = 0;
> @@ -2080,8 +2081,11 @@ int finalize_object_file_flags(const char *tmpfile, const char *filename,
> }
> if (!(flags & FOF_SKIP_COLLISION_CHECK)) {
> ret = check_collision(tmpfile, filename);
> - if (ret == CHECK_COLLISION_DEST_VANISHED)
> + if (ret == CHECK_COLLISION_DEST_VANISHED) {
> + if (retries++ > 5)
> + return error(_("unable to write repeatedly vanishing file %s"), filename);
> goto retry;
> + }
> else if (ret)
> return -1;
> }
Sounds sensible.
> Otherwise, I think the logic looks good.
>
> -Peff
Thanks.
next prev parent reply other threads:[~2025-01-03 20:25 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-03 8:19 [PATCH 0/2] object-file: retry linking file into place when occluding file vanishes Patrick Steinhardt
2025-01-03 8:19 ` [PATCH 1/2] object-file: rename variables in `check_collision()` Patrick Steinhardt
2025-01-03 19:10 ` Jeff King
2025-01-03 8:19 ` [PATCH 2/2] object-file: retry linking file into place when occluding file vanishes Patrick Steinhardt
2025-01-03 16:18 ` Junio C Hamano
2025-01-03 19:40 ` Jeff King
2025-01-03 19:59 ` Jeff King
2025-01-03 22:29 ` Junio C Hamano
2025-01-06 11:11 ` Patrick Steinhardt
2025-01-07 1:25 ` Jeff King
2025-01-03 20:25 ` Junio C Hamano [this message]
2025-01-06 11:11 ` Patrick Steinhardt
2025-01-06 9:24 ` [PATCH v2 0/3] " Patrick Steinhardt
2025-01-06 9:24 ` [PATCH v2 1/3] object-file: rename variables in `check_collision()` Patrick Steinhardt
2025-01-06 9:24 ` [PATCH v2 2/3] object-file: don't special-case missing source file in collision check Patrick Steinhardt
2025-01-06 9:24 ` [PATCH v2 3/3] object-file: retry linking file into place when occluding file vanishes Patrick Steinhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqsepzprul.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=ps@pks.im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).