Re: What's cooking in git.git (Jul 2016, #05; Wed, 13)
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- Jul 13, 2016, 17:40 UTC
- Message-ID
- <CACsJy8CVJr6-9CnyrOU4UoPPGu6Ovn_=-2YKeqC8Lp_rVnh5fg@mail.gmail.com>
- In-Reply-To
- <xmqqy4551nph.fsf@gitster.mtv.corp.google.com>
On Wed, Jul 13, 2016 at 6:56 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 13 quoted lines
> * nd/pack-ofs-4gb-limit (2016-07-13) 7 commits > - fsck: use streaming interface for large blobs in pack > - pack-objects: do not truncate result in-pack object size on 32-bit systems > - index-pack: correct "offset" type in unpack_entry_data() > - index-pack: report correct bad object offsets even if they are large > - index-pack: correct "len" type in unpack_data() > - sha1_file.c: use type off_t* for object_info->disk_sizep > - pack-objects: pass length to check_pack_crc() without truncation > > "git pack-objects" and "git index-pack" mostly operate with off_t > when talking about the offset of objects in a packfile, but there > were a handful of places that used "unsigned long" to hold that > value, leading to an unintended truncation.
On the subject of truncation, there is something else I should note. The field sd_size in struct stat_data is 32 bits, so large files will overflow it too, regardless of platforms. I did not do anything because I checked and double checked and was pretty sure we did not use it for anything meaningful (as a file size). To us, it's just another random number, like st_ino, that we check to detect if a file has changed.
It's probably just an oversight (it comes from the very first "the information manager from hell" commit). But it's not worth changing index format now to extend it to 64 bits, I think. So it's ok, no worry about it, but we should probably make clear that this is not true file size, and don't anybody ever use it as such. Maybe rename it to "size_hash" or something.
-- Duy