On Thu, Jul 5, 2018 at 8:54 PM Derrick Stolee <stolee@xxxxxxxxx> wrote:
> The final pair of chunks for the multi-pack-index file stores the object
> offsets. We default to using 32-bit offsets as in the pack-index version
> 1 format, but if there exists an offset larger than 32-bits, we use a
> trick similar to the pack-index version 2 format by storing all offsets
> at least 2^31 in a 64-bit table; we use the 32-bit table to point into
> that 64-bit table as necessary.
>
> We only store these 64-bit offsets if necessary, so create a test that
> manipulates a version 2 pack-index to fake a large offset. This allows
> us to test that the large offset table is created, but the data does not
> match the actual packfile offsets. The multi-pack-index offset does match
> the (corrupted) pack-index offset, so a future feature will compare these
> offsets during a 'verify' step.
>
> Signed-off-by: Derrick Stolee <dstolee@xxxxxxxxxxxxx>
> ---
> diff --git a/t/t5319-multi-pack-index.sh b/t/t5319-multi-pack-index.sh
> @@ -6,25 +6,28 @@ test_description='multi-pack-indexes'
> +# usage: corrupt_data <file> <pos> [<data>]
> +corrupt_data() {
Style: corrupt_data () {
> + file=$1
> + pos=$2
> + data="${3:-\0}"
> + printf "$data" | dd of="$file" bs=1 seek="$pos" conv=notrunc
> +}
> +
> +# Force 64-bit offsets by manipulating the idx file.
> +# This makes the IDX file _incorrect_ so be careful to clean up after!
> +test_expect_success 'force some 64-bit offsets with pack-objects' '
> + mkdir objects64 &&
> + mkdir objects64/pack &&
> + pack64=$(git pack-objects --index-version=2,0x40 objects64/pack/test-64 <obj-list) &&
> + idx64=objects64/pack/test-64-$pack64.idx &&
> + chmod u+w $idx64 &&
I guess you don't have to worry about the POSIXPERM prerequisite here
because the file is already writable on Windows, right?
> + corrupt_data $idx64 2899 "\02" &&
> + midx64=$(git multi-pack-index write --object-dir=objects64) &&
> + midx_read_expect 1 62 5 objects64 " large_offsets"
> '
