From acd7160201ae908d3e0fccee19685ab19b1be720 Mon Sep 17 00:00:00 2001 From: =?utf8?q?Martin=20=C3=85gren?= Date: Tue, 5 Jan 2021 20:23:48 +0100 Subject: [PATCH] midx: don't peek into `struct lock_file` MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit Similar to the previous commits, avoid peeking into the `struct lock_file`. Use the lock file API instead. The two functions we're calling here double-check that the tempfile is indeed "active", which is arguably overkill considering how we took the lock on the line immediately above. More importantly, this future-proofs us against, e.g., other code appearing between these two lines or the lock file and/or tempfile internals changing. Signed-off-by: Martin Ågren Reviewed-by: Derrick Stolee Signed-off-by: Junio C Hamano --- midx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/midx.c b/midx.c index 79c282b070..9d41b9c271 100644 --- a/midx.c +++ b/midx.c @@ -918,7 +918,7 @@ static int write_midx_internal(const char *object_dir, struct multi_pack_index * (pack_name_concat_len % MIDX_CHUNK_ALIGNMENT); hold_lock_file_for_update(&lk, midx_name, LOCK_DIE_ON_ERROR); - f = hashfd(lk.tempfile->fd, lk.tempfile->filename.buf); + f = hashfd(get_lock_file_fd(&lk), get_lock_file_path(&lk)); FREE_AND_NULL(midx_name); if (packs.m) -- 2.32.0.93.g670b81a890