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

[Ted Nyman <tnyman@openai.com>]

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.

> More importantly, why don't we need to close tmpfile_fd anymore? We hand
> it off to run_command(), which will always close it. So I _think_ it was
> always wrong to close it ourselves here. If so, then could this hunk
> become a preparatory commit on its own?

You're right: run_command() already closes ip.in, so the old
close(tmpfile_fd) was a double-close. That cleanup is independent, and
I can pull it into a preparatory patch if that would make the series
easier to follow.

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

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.

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

Thanks,
Ted