All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 3/7] odb/source-packed: flag known-bad objects as corrupt and not missing
Date: Tue, 18 Aug 2026 11:17:47 -0700	[thread overview]
Message-ID: <xmqq5x17z41g.fsf@gitster.g> (raw)
In-Reply-To: <20260818-pks-odb-generic-corrupt-objects-v1-3-ec234567510f@pks.im> (Patrick Steinhardt's message of "Tue, 18 Aug 2026 16:19:30 +0200")

Patrick Steinhardt <ps@pks.im> writes:

> When reading a packed object that doesn't verify we mark it as bad and
> indicate to the caller that we failed reading the object despite the
> fact that it supposedly exists. This matches the semantics we have now
> established in a preceding commit, where we discern failure to read a
> corrupt object from a missing object.
>
> What doesn't work yet though is when a call tries to read an object that
> has already been marked as corrupt in a previous call. In that case,
> `find_pack_entry()` will tell us that the object in question does not
> exist, and consequently we'll not flag the object as corrupt but as
> missing.

Thanks for attacking this one.  I've always felt it awkward that we
treat a corrupt/unreadable object as if we do not have it, and we
even silently recover from it if we have another copy, making fsck
practically the only thing that notices such breakages.

>  int fill_midx_entry(struct multi_pack_index *m,
>  		    const struct object_id *oid,
> -		    struct pack_entry *e)
> +		    struct pack_entry *e,
> +		    struct packed_git **bad_pack)
>  {
>  	uint32_t pos;
>  	uint32_t pack_int_id;
> @@ -618,8 +619,11 @@ int fill_midx_entry(struct multi_pack_index *m,
>  		return 0;
>  
>  	if (oidset_size(&p->bad_objects) &&
> -	    oidset_contains(&p->bad_objects, oid))
> +	    oidset_contains(&p->bad_objects, oid)) {
> +		if (bad_pack && !*bad_pack)
> +			*bad_pack = p;
>  		return 0;
> +	}

Hmph, so the idea is that if you have even one bad thing, you are
marked as bad, because who knows what other parts of you are broken?


  reply	other threads:[~2026-08-18 18:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-18 14:19 [PATCH 0/7] odb: handle `OBJECT_INFO_DIE_IF_CORRUPT` generically Patrick Steinhardt
2026-08-18 14:19 ` [PATCH 1/7] odb/source: discern missing and corrupt objects Patrick Steinhardt
2026-08-18 18:00   ` Junio C Hamano
2026-08-18 14:19 ` [PATCH 2/7] odb/source-inmemory: signal missing objects via positive return Patrick Steinhardt
2026-08-18 18:05   ` Junio C Hamano
2026-08-18 14:19 ` [PATCH 3/7] odb/source-packed: flag known-bad objects as corrupt and not missing Patrick Steinhardt
2026-08-18 18:17   ` Junio C Hamano [this message]
2026-08-18 14:19 ` [PATCH 4/7] odb/source-loose: distinguish missing and corrupt objects Patrick Steinhardt
2026-08-18 18:23   ` Junio C Hamano
2026-08-18 14:19 ` [PATCH 5/7] odb/source-files: signal mark objects via positive return Patrick Steinhardt
2026-08-18 18:58   ` Junio C Hamano
2026-08-18 14:19 ` [PATCH 6/7] odb/source: allow `read_object_info()` to bubble up error messages Patrick Steinhardt
2026-08-18 14:19 ` [PATCH 7/7] odb: handle `OBJECT_INFO_DIE_IF_CORRUPT` generically Patrick Steinhardt

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=xmqq5x17z41g.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=ps@pks.im \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.