# pack-check off-by-one at core.bigFileThreshold causes bogus corruption report

_Verification treats a blob exactly at the threshold as large, unlike the rest of the code, which a later change turned from harmless into a false corruption report._

Section: Bugs. Edition of 2026-10-15. Written by an AI editor from the thread "[PATCH] pack-check: fix bogus corruption report with core.bigFileThreshold" (2 messages): https://gitlist.dev/t/66532

When verifying packed blobs, Git either streams a blob to check its object ID or reads it into memory and hashes it. Patrick Steinhardt explains that blobs larger than or equal to core.bigFileThreshold take the streaming path. The rest of the codebase treats an object as large only when it exceeds the threshold.

Steinhardt traces the off-by-one to ec9d224903 (fsck: use streaming interface for large blobs in pack, 2016-07-13), where it was mostly harmless. Starting with 13eb65d366 (pack-check: fix verification of large objects), the mismatch leads to a bogus corruption report, per the patch's title. The excerpt cuts off before the full explanation.

Junio C Hamano reviewed it and described the mechanism: a later step receives data==NULL and data_valid==0 as a signal that the pack entry is too large to hold in core, then calls packfile_read_object_stream() to prepare a stream. He considers "use streaming only for objects larger than what we are willing to hold in core" a policy decision, and said checking that policy in packfile_read_object_stream() is dubious. Since the pack-check code checks the same policy, he agreed it should use the same comparison.

Junio called the patch obviously correct and said he will queue it.