Bug with corruption on clone/fsck/... with large packs + 64-bit Windows, problem with usage of "long" datatype for sizes/offsets?
- From
- Dr.-Ing. Christoph Cullmann <cullmann@absint.com>
- Date
- Aug 11, 2017, 07:04 UTC
- Message-ID
- <1232852793.287524.1502435085656.JavaMail.zimbra@absint.com>
Hi,
on Windows 64-bit, for a repository having a .pack file > 4GB I get during cloning:
$ git clone file:///repositories/test.git test Cloning into 'test'... remote: Counting objects: 210294, done. remote: error: bad object header remote: error: bad object header remote: fatal: packed object cae50116ebe36de8bded4811bd262d90670bde2f (stored in ./objects/pack/pack-30ba8b19b029cc6554853ae07729aa807995ebb8.pack) is corrupt error: git upload-pack: git-pack-objects died with error. fatal: git upload-pack: aborting due to possible repository remote: aborting due to possible repository corruption on the remote side. corruption on the remote side. fatal: early EOF fatal: index-pack failed
We use git 2.14.1, the 64-bit version.
On systems which have (long int) == 64-bit datatype, all works well, e.g. Linux 64-bit. (same goes for fscks/...., they work on this git on Linux 64-bit, not on Windows 64-bit)
It seems the Windows port did take care of using the right 64-bit offsets and all in the OS specific parts, but things like pack-objects.c in the generic parts use "unsigned long" like it behaves like size_t (at least on the first glance).
As I think the issue is in the generic part, I report this here, not on the Windows list, thought it seems to be an IL32P64 related issue.
Greetings Christoph
-- ----------------------------- Dr.-Ing. Christoph Cullmann --------- AbsInt Angewandte Informatik GmbH Email: cullmann@AbsInt.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANY WWW: http://www.AbsInt.com -------------------------------------------------------------------- Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234