From: "Dr.-Ing. Christoph Cullmann" <cullmann@absint.com>
To: git@vger.kernel.org
Subject: Bug with corruption on clone/fsck/... with large packs + 64-bit Windows, problem with usage of "long" datatype for sizes/offsets?
Date: Fri, 11 Aug 2017 09:04:45 +0200 (CEST) [thread overview]
Message-ID: <1232852793.287524.1502435085656.JavaMail.zimbra@absint.com> (raw)
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
next reply other threads:[~2017-08-11 7:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-11 7:04 Dr.-Ing. Christoph Cullmann [this message]
2017-08-14 16:05 ` Bug with corruption on clone/fsck/... with large packs + 64-bit Windows, problem with usage of "long" datatype for sizes/offsets? Johannes Schindelin
2017-08-14 17:07 ` Stefan Beller
2017-08-14 18:57 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1232852793.287524.1502435085656.JavaMail.zimbra@absint.com \
--to=cullmann@absint.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).