Re: [PATCH v3 15/24] midx: write object offsets
On 7/6/2018 1:27 AM, Eric Sunshine wrote:
On Thu, Jul 5, 2018 at 8:54 PM Derrick Stolee 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
---
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 []
+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
I guess you don't have to worry about the POSIXPERM prerequisite here
because the file is already writable on Windows, right?
Correct. And I want this test to still run on Windows.
Thanks,
-Stolee
Re: [PATCH v3 15/24] midx: write object offsets
On Thu, Jul 5, 2018 at 8:54 PM Derrick Stolee 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
> ---
> 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 []
> +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 + 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"
> '
