git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Ted Nyman <tnyman@openai.com>
Date
Jul 26, 2026, 10:04 UTC
Message-ID
<20260726100421.12648-1-tnyman@openai.com>
In-Reply-To
<20260726092027.GA3529827@coredump.intra.peff.net>
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

Previous: Jeff KingNext: Jeff King
Message 42 of 57 in “packfile URIs: support concurrent downloads”
  1. 0/2 packfile URIs: support concurrent downloadsTed Nyman, Jul 13, 2026
  2. 1/2 http: use unique tempfiles for packfile URI downloadsTed Nyman, Jul 13, 2026
  3. Junio C HamanoJul 14, 2026
  4. Ted NymanJul 14, 2026
  5. Taylor BlauJul 14, 2026
  6. Jeff KingJul 14, 2026
  7. Junio C HamanoJul 14, 2026
  8. Ted NymanJul 14, 2026
  9. Taylor BlauJul 14, 2026
  10. Jeff KingJul 14, 2026
  11. Jeff KingJul 14, 2026
  12. 2/2 fetch-pack: accept "pack" output for packfile URIsTed Nyman, Jul 13, 2026
  13. Jeff KingJul 14, 2026
  14. Jeff KingJul 14, 2026
  15. Ted NymanJul 14, 2026
  16. Jeff KingJul 14, 2026
  17. Taylor BlauJul 14, 2026
  18. 0/2 packfile URIs: support concurrent downloadsTed Nyman, Jul 20, 2026
  19. 1/2 http: avoid concurrent appends to partial packsTed Nyman, Jul 20, 2026
  20. Junio C HamanoJul 21, 2026
  21. 2/2 fetch-pack: accept "pack" output for packfile URIsTed Nyman, Jul 20, 2026
  22. 0/3 packfile URIs: support concurrent downloadsTed Nyman, Jul 21, 2026
  23. 1/3 http-fetch: correct --index-pack-arg documentationTed Nyman, Jul 21, 2026
  24. 2/3 http: avoid concurrent appends to partial packsTed Nyman, Jul 21, 2026
  25. 3/3 fetch-pack: accept "pack" output for packfile URIsTed Nyman, Jul 21, 2026
  26. Junio C HamanoJul 24, 2026
  27. Jeff KingJul 25, 2026
  28. Jeff KingJul 25, 2026
  29. Jeff KingJul 25, 2026
  30. Jeff KingJul 25, 2026
  31. Junio C HamanoJul 25, 2026
  32. 0/3 packfile URIs: support concurrent downloadsTed Nyman, Jul 24, 2026
  33. 1/3 http-fetch: correct --index-pack-arg documentationTed Nyman, Jul 24, 2026
  34. Taylor BlauJul 24, 2026
  35. 2/3 http: avoid concurrent appends to partial packsTed Nyman, Jul 24, 2026
  36. 3/3 fetch-pack: accept "pack" output for packfile URIsTed Nyman, Jul 24, 2026
  37. Taylor BlauJul 24, 2026
  38. 0/3 packfile URIs: support concurrent downloadsTed Nyman, Jul 26, 2026
  39. 1/3 http-fetch: correct --index-pack-arg documentationTed Nyman, Jul 26, 2026
  40. 2/3 http: avoid concurrent appends to partial packsTed Nyman, Jul 26, 2026
  41. Jeff KingJul 26, 2026
  42. Ted NymanJul 26, 2026
  43. Jeff KingJul 26, 2026
  44. 3/3 fetch-pack: accept "pack" output for packfile URIsTed Nyman, Jul 26, 2026
  45. Jeff KingJul 26, 2026
  46. 0/6 packfile URIs: support concurrent downloadsTed Nyman, Jul 27, 2026
  47. 1/6 http-fetch: correct --index-pack-arg documentationTed Nyman, Jul 27, 2026
  48. 2/6 http: avoid closing index-pack input twiceTed Nyman, Jul 27, 2026
  49. Jeff KingAug 1, 2026
  50. 3/6 http: accept HTTP 416 for complete partial packsTed Nyman, Jul 27, 2026
  51. Jeff KingAug 1, 2026
  52. 4/6 http: avoid concurrent appends to partial packsTed Nyman, Jul 27, 2026
  53. 5/6 http: permit unlinking partial packs on WindowsTed Nyman, Jul 27, 2026
  54. 6/6 fetch-pack: accept "pack" output for packfile URIsTed Nyman, Jul 27, 2026
  55. Junio C HamanoJul 29, 2026
  56. Jeff KingAug 1, 2026
  57. Junio C HamanoAug 8, 2026

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.