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

Re: [PATCH] pack-objects: protect against disappearing packs

From
Johannes Sixt <j.sixt@viscovery.net>
Date
Oct 14, 2011, 07:06 UTC
Message-ID
<4E97DF63.104@viscovery.net>
In-Reply-To
<20111014012320.GA4395@sigill.intra.peff.net>
Am 10/14/2011 3:23, schrieb Jeff King:
Show 7 quoted lines
> In practice, however, adding this check still has value, for
> three reasons.
> 
>   1. If you have a reasonable number of packs and/or a
>      reasonable file descriptor limit, you can keep all of
>      your packs open simultaneously. If this is the case,
>      then the race is impossible to trigger.

On Windows, we cannot remove files that are open. If I understand correctly, this patch keeps more files open for a longer time. Is there any chance that packfiles remain now open until an unlink() call?

I am not worried about parallel processes (we already have a problem there), but that this can now happen within a single process, i.e., that a single git-repack -a -d -f would now try to unlink a pack file that it opened itself and did not close timely.

I'll test your patch later this weekend to see whether the test suite finds something. But perhaps you know the answer already?

-- Hannes
Previous: Jeff KingNext: Jeff King
Message 6 of 10 in “pack-objects: protect against disappearing packs”
  1. pack-objects: protect against disappearing packsJeff King, Oct 14, 2011
  2. Jeff KingOct 14, 2011
  3. Nicolas PitreOct 14, 2011
  4. Nicolas PitreOct 14, 2011
  5. Jeff KingOct 14, 2011
  6. Johannes SixtOct 14, 2011
  7. Jeff KingOct 14, 2011
  8. Johannes SixtOct 14, 2011
  9. 1/2 pack-objects: protect against disappearing packsJeff King, Oct 14, 2011
  10. 2/2 downgrade "packfile cannot be accessed" errors to warningsJeff King, Oct 14, 2011

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.