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

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

> 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.

> > 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.

> > 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