Re: [PATCH v5 2/3] http: avoid concurrent appends to partial packs

From: Jeff King <peff@peff.net>
Date: Jul 26, 2026, 10:27 UTC
Message-ID: <20260726102712.GA3535709@coredump.intra.peff.net>
In-Reply-To: <20260726100421.12648-1-tnyman@openai.com>

On Sun, Jul 26, 2026 at 03:04:21AM -0700, Ted Nyman wrote:

Show 8 quoted lines

> On Sun, Jul 26, 2026 at 05:20:27AM -0400, Jeff King wrote:
> > I wonder if we still need this or not.
> 
> I think so, but wouldn't bet the farm on it. A concurrent downloader can
> complete the staging file before another downloader issues its Range
> request. That request then starts exactly at EOF, so the server can
> respond with 416. The existing regression test exercises that case, and
> we still need to let index-pack validate the completed local pack.

Yeah, the big question there for me is whether a server would return a 416 in such a case. It seems reasonable that a client might know it has N bytes but not the full size, and ask for "N-", expecting to get some equivalent of a 0-byte read(). Whereas a 416 does not make it clear at all whether the range is nonsense, or if you happened to be at EOF.

But sadly we do not seem to live in that world, based on a few tests. So I agree we do need it to cover that edge case.

If you are splitting things out of the patch, can we do the same for this 416 handling? It is already a problem even without concurrency if you happen to get the full file but then fail for other reasons before indexing the pack (transient system errors, etc).

To be clear, I can live with things as they are and I don't want to make too much work for you in splitting. But I'm hoping that feeding it to an electronic friend could do that split without much effort.

Show 10 quoted lines

> > That is...subtle as hell. I really wonder if it would be worth
> > introducing the basic form of this (just opening once with O_RDWR) and
> > then doing the Windows hackery on top as a separate commit.
> 
> I'm certainly not an expert on the Windows side, so I had to track this
> down in the MinGW open() wrapper. The existing-file O_RDWR path includes
> FILE_SHARE_DELETE, while creating a new file falls back to _wopen()
> without it. The loop creates the file with O_EXCL if needed, closes that
> descriptor, and retries through the existing-file path; a racing creator
> that sees EEXIST also retries.

Yeah, I understand it now after reading the commit message and the code several times. The loop is what I think is subtle, but I can't see a more obvious way of writing it that deals with all of the possible combinations and races.

> I kept those pieces together to avoid an intermediate state without the
> required sharing behavior on MinGW, but I'm happy to split them if you
> think it would be clearer.

IMHO it is the lesser of two evils. Not because we won't eventually end up with the subtle loop, but because it helps make the desired change in the "simpler" version much easier to see. IOW, the Windows patch is always going to be confusing, but we can at least salvage the original.

Show 5 quoted lines

> > Hopefully this perl script (and the accompanying fifo monstrosities)
> > can sit here for eternity un-looked-at by human eyes, just quietly
> > doing their job until the heat death of the universe.
> 
> I thought you, of all people, might appreciate a little more Perl. ;-)

Well, if we have to write something like that, obviously Perl is the right choice. ;) It's more the custom socket handling. E.g., there are sometimes subtle issues around listen-port allocation, especially when we run the same test concurrently with --stress. Your script solves it by asking for a dynamic port and then passing that back to the caller over the fifo. That should work reliably, I think, it's just not our usual solution (but usually we are constrained to having to tell apache the correct port up front, which means we need to pick an unambiguous one ourselves).

-Peff