Message ID | 1448ca0d2ba265db2dce414a7f7d6b1f4bcb5a08.1624314293.git.me@ttaylorr.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | multi-pack reachability bitmaps | expand |
On Mon, Jun 21, 2021 at 06:25:15PM -0400, Taylor Blau wrote: > When writing a new multi-pack index, write_midx_internal() attempts to > clean up any auxiliary files (currently just the MIDX's `.rev` file, but > soon to include a `.bitmap`, too) corresponding to the MIDX it's > replacing. > > This step should happen after the new MIDX is written into place, since > doing so beforehand means that the old MIDX could be read without its > corresponding .rev file. Good catch. The patch looks obviously correct. -Peff
diff --git a/midx.c b/midx.c index fa23d57a24..40eb7974ba 100644 --- a/midx.c +++ b/midx.c @@ -1076,10 +1076,11 @@ static int write_midx_internal(const char *object_dir, struct multi_pack_index * if (flags & MIDX_WRITE_REV_INDEX) write_midx_reverse_index(midx_name, midx_hash, &ctx); - clear_midx_files_ext(the_repository, ".rev", midx_hash); commit_lock_file(&lk); + clear_midx_files_ext(the_repository, ".rev", midx_hash); + cleanup: for (i = 0; i < ctx.nr; i++) { if (ctx.info[i].p) {
When writing a new multi-pack index, write_midx_internal() attempts to clean up any auxiliary files (currently just the MIDX's `.rev` file, but soon to include a `.bitmap`, too) corresponding to the MIDX it's replacing. This step should happen after the new MIDX is written into place, since doing so beforehand means that the old MIDX could be read without its corresponding .rev file. Signed-off-by: Taylor Blau <me@ttaylorr.com> --- midx.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)