On Thu, Jul 14, 2016 at 06:45:47PM +0200, Johannes Sixt wrote: > Am 14.07.2016 um 17:47 schrieb Johannes Schindelin: > > On Thu, 30 Jun 2016, Jeff King wrote: > > > The ustar format only has room for 11 (or 12, depending on > > > some implementations) octal digits for the size and mtime of > > > each file. For values larger than this, we have to add pax > > > extended headers to specify the real data, and git does not > > > yet know how to do so. > > > > > > [...] > > > t/t5000/19f9c8273ec45a8938e6999cb59b3ff66739902a | Bin 0 -> 2048 bytes > > > > It appears that this blob cannot be read when sizeof(unsigned long) == 4. > > This happens to break the t5000 test on Windows, where that comparison > > holds true. > > The problem occurs in parse_sha1_header_extended(), where the calculation of > the size in the object header overflows our 32-bit unsigned long. Yep, unsurprising. I do think git is wrong to use "unsigned long" there. It really ought to be "size_t". My understanding is that 64-bit Windows is LLP64, which means that you cannot currently have blobs greater than 4GB there, even though it would work correctly with size_t. Switching all of the things that look at blob sizes to size_t will be a big job, though. -Peff -- 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