Re: [PATCH v3 08/25] Provide zlib's uncompress2 from compat/zlib-compat.c
- From
Philip Oakley <philipoakley@iee.email>
- Date
- Aug 18, 2021, 11:53 UTC
- Message-ID
- <916368b8-7c6f-09df-3dd8-03a4f99f9d1a@iee.email>
- In-Reply-To
- <CAFQ2z_P1EnNYPxiTZ8GeTTVsJaa0S0vz5M4kqu7Kf3yGbUt0kQ@mail.gmail.com>
On 18/08/2021 11:39, Han-Wen Nienhuys wrote:
Show 14 quoted lines
> On Wed, Aug 18, 2021 at 12:14 PM Philip Oakley <philipoakley@iee.email> wrote: >> On 17/08/2021 14:39, Han-Wen Nienhuys via GitGitGadget wrote: >>> From: Han-Wen Nienhuys <hanwen@google.com> >>> >>> This will be needed for reading reflog blocks in reftable. >> How large might the reftable become? In particular will it exceed the >> 32bit Long limit on Windows? > A reftable file is organized as a sequence of blocks. Each block has > max size 2^24, and the zlib compression is done per-block. So zlib > should not introduce a new 4G limit. The intra-file offsets for the > blocks themselves are encoded either as varint (index values) or as > uint64 (file footer), so reftable files beyond 4G should be no > problem. >
Thanks, that's good to know for planning any Git upgrade to cope with 4GB file sizes on Windows.
Philip