Am 14.07.2016 um 19:08 schrieb Junio C Hamano:
Johannes Sixt <j6t@xxxxxxxx> 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
--
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