mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <>
To: Taylor Blau <>
Cc:, Junio C Hamano <>,
	Derrick Stolee <>,
	Victoria Dye <>
Subject: Re: [PATCH] midx.c: clear auxiliary MIDX files first
Date: Wed, 26 Oct 2022 01:41:55 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, Oct 25, 2022 at 02:25:20PM -0400, Taylor Blau wrote:

> Since they were added in c528e17966 (pack-bitmap: write multi-pack
> bitmaps, 2021-08-31), the routine to remove MIDXs removed the
> multi-pack-index file itself before removing its associated .bitmap and
> .rev file(s), if any.
> This creates a window where a MIDX's .bitmap file exists without its
> corresponding MIDX. If a reader tries to load a MIDX bitmap during that
> time, they will get a warning, and the MIDX bitmap code will gracefully
> degrade.
> Remove this window entirely by removing the MIDX last, and removing its
> auxiliary files first.

We remove that window, but don't we create a new one where a reader may
see the midx but not the bitmap? That won't generate a warning (it just
looks like a midx that never had a bitmap generated), but it will cause
the reader to follow the slow, non-bitmap path.

Ideally this would just be atomic, but short of stuffing the metadata
into the same file, we can't do that. But the replacement of the midx
file itself is atomic, and I'd think everything would (or should at
least) follow from there.

I.e., why are we reading the midx bitmap without having opened the midx
file? Ideally we'd be holding a descriptor for it.


  reply	other threads:[~2022-10-26  5:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-25 18:25 [PATCH] midx.c: clear auxiliary MIDX files first Taylor Blau
2022-10-26  5:41 ` Jeff King [this message]
2022-10-26 13:31   ` Derrick Stolee
2022-10-26 19:59     ` Taylor Blau
2022-10-27 20:28     ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).