From 79334a214ba4c9d7b2b5e2ed1c9b9c8ed208d406 Mon Sep 17 00:00:00 2001 From: Kristofer Karlsson Date: Thu, 28 May 2026 11:51:24 +0200 Subject: [PATCH] t5608, t7508: require LONG_IS_64BIT for >4GB tests The >4GB clone tests in t5608 (tests 5-6) fail on Windows because the server-side pack-objects still uses `unsigned long` for object sizes. On Windows x86_64 (LLP64), `unsigned long` is 32 bits, so pack-objects dies in cast_size_t_to_ulong() when it encounters a 4294967297-byte object: fatal: object too large to read on this platform: 4294967297 is cut off to 1 The streaming/odb/index-pack side was widened to size_t in js/objects-larger-than-4gb-on-windows, but pack-objects was deliberately left as a stop-gap with cast_size_t_to_ulong() at the type boundaries. Until the pack-objects path is also widened, gate these tests on LONG_IS_64BIT so they skip on Windows rather than failing. Similarly, t7508's "status does not re-read unchanged 4 or 8 GiB file" test fails on Windows because ftruncate is implemented via _chsize which takes a `long` parameter, overflowing at 2 GiB. The subsequent git-add and git-diff-index also route through object_info.sizep (unsigned long), which would truncate. Add LONG_IS_64BIT here too. Note: LONG_IS_64BIT is a stop-gap, not the right long-term fix. Once the remaining `unsigned long` code paths (pack-objects, object_info.sizep, and the MSVC ftruncate compat shim) are widened to use size_t, these tests should work on all 64-bit platforms and the LONG_IS_64BIT prerequisite can be dropped. Signed-off-by: Kristofer Karlsson --- t/t5608-clone-2gb.sh | 6 +++--- t/t7508-status.sh | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/t/t5608-clone-2gb.sh b/t/t5608-clone-2gb.sh index 4f8a95ddda411c..86994beccb472d 100755 --- a/t/t5608-clone-2gb.sh +++ b/t/t5608-clone-2gb.sh @@ -49,7 +49,7 @@ test_expect_success 'clone - with worktree, file:// protocol' ' ' -test_expect_success SIZE_T_IS_64BIT,EXPENSIVE 'set up repo with >4GB object' ' +test_expect_success SIZE_T_IS_64BIT,LONG_IS_64BIT,EXPENSIVE 'set up repo with >4GB object' ' large_blob_size=$((4*1024*1024*1024+1)) && git init --bare 4gb-repo && head_oid=$(test-tool synthesize pack \ @@ -60,7 +60,7 @@ test_expect_success SIZE_T_IS_64BIT,EXPENSIVE 'set up repo with >4GB object' ' git -C 4gb-repo symbolic-ref HEAD refs/heads/main ' -test_expect_success SIZE_T_IS_64BIT,EXPENSIVE 'clone >4GB object via unpack-objects' ' +test_expect_success SIZE_T_IS_64BIT,LONG_IS_64BIT,EXPENSIVE 'clone >4GB object via unpack-objects' ' # The synthesized pack has five objects, so a large unpack limit keeps # fetch-pack on the unpack-objects path. git -c fetch.unpackLimit=100 clone --bare \ @@ -76,7 +76,7 @@ test_expect_success SIZE_T_IS_64BIT,EXPENSIVE 'clone >4GB object via unpack-obje test "$source_blob" = "$clone_blob" ' -test_expect_success SIZE_T_IS_64BIT,EXPENSIVE 'clone with >4GB object via index-pack' ' +test_expect_success SIZE_T_IS_64BIT,LONG_IS_64BIT,EXPENSIVE 'clone with >4GB object via index-pack' ' # Force fetch-pack to hand the pack to index-pack instead. git -c fetch.unpackLimit=1 clone --bare \ "file://$(pwd)/4gb-repo" 4gb-clone-index && diff --git a/t/t7508-status.sh b/t/t7508-status.sh index c2057bc94c38c1..895945f3990226 100755 --- a/t/t7508-status.sh +++ b/t/t7508-status.sh @@ -1773,7 +1773,7 @@ test_expect_success 'slow status advice when core.untrackedCache true, and fsmon ) ' -test_expect_success EXPENSIVE 'status does not re-read unchanged 4 or 8 GiB file' ' +test_expect_success LONG_IS_64BIT,EXPENSIVE 'status does not re-read unchanged 4 or 8 GiB file' ' ( mkdir large-file && cd large-file &&