Large object issue (Windows)
- Date: Mon, 4 Mar 2019 19:04:02 -0500
- From: Patrick Hogg <phogg@xxxxxxxxxxxx>
- Subject: Large object issue (Windows)
While investigating the last issue I reported (and fixed) I was trying
to come up with a good test case for repos with large objects. In the
process I found an issue on Windows with objects at least 4g large:
git init test
echo "*.exe binary" > .gitattributes
truncate -s 4g nullbytes.exe
git stage .
git commit -m "Test"
# This will break, complaining that the object is corrupt.
git fsck --full
# This will also break, complaining that the object is corrupt.
I did some investigation and I think that this is a porting issue.
unpack_object_header_buffer in packfile.c uses an unsigned long for the
size. On Linux this will be 64 bits (at least on the Linux systems I've
tried) but on Windows it's 32 bits. The code then decides that the
object header is bad and bombs. However, if I move the repo to a Linux
machine it can handle the data just fine. (And ironically git generated
the object header when storing the object!)
Is there any reason not to switch the unsigned longs in
unpack_object_header_buffer (and its callers, wherever that may lead)
to uint64_t? (Or any potential pitfalls in doing so that I would need
to look out for?)