On Wed, Jul 13, 2016 at 6:56 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > * 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html