Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

From: Johannes Sixt <j6t@kdbg.org>
Date: Jul 14, 2016, 20:52 UTC
Message-ID: <3d71cf3a-44c7-0620-0375-fb7ecf2fac13@kdbg.org>
In-Reply-To: <xmqqa8hkrvu5.fsf@gitster.mtv.corp.google.com>

Am 14.07.2016 um 19:08 schrieb Junio C Hamano:

Show 29 quoted lines

> Johannes Sixt <j6t@kdbg.org> writes:
>
>> 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.
>
> OK, then we'd want something that measures how big "unsigned long"
> is, and use it as a lazy prerequisite 64BIT_LONG, tweaking the other
> patch to t0006 the other Johannes sent yesterday.
>
> Dscho?  I'll revert the merge of 'js/t0006-for-v2.9.2' out of
> 'next' so that we can replace it with your newer version, but it
> needs to be massaged to lose the strong linkage with "time", as
> it is no longer "is our time big enough", I would think.

My first thought was that this is not warranted because t0006 is about commit time stamps, but the huge-tar breakage is file sizes, and the cases should be treated differently.

But on second thought, under the hood, both boil down to the size of unsigned long in our implementation. It may make sense to tie both cases to the same prerequisite.

On third thought, however, I think the two requirements could diverge in the future. The file size case should depend on the size of size_t. The timestamp case may become dependent on the size of time_t if we decide to move timestamp handling away from unsigned long: in modern(!) Microsoft SDKs, time_t is 64 bits, but unsigned long is 32 bits, in both the 32-bit and 64-bit environments!

-- Hannes