* Bug with corruption on clone/fsck/... with large packs + 64-bit Windows, problem with usage of "long" datatype for sizes/offsets?
@ 2017-08-11 7:04 Dr.-Ing. Christoph Cullmann
2017-08-14 16:05 ` Johannes Schindelin
0 siblings, 1 reply; 4+ messages in thread
From: Dr.-Ing. Christoph Cullmann @ 2017-08-11 7:04 UTC (permalink / raw
To: git
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Bug with corruption on clone/fsck/... with large packs + 64-bit Windows, problem with usage of "long" datatype for sizes/offsets?
2017-08-11 7:04 Bug with corruption on clone/fsck/... with large packs + 64-bit Windows, problem with usage of "long" datatype for sizes/offsets? Dr.-Ing. Christoph Cullmann
@ 2017-08-14 16:05 ` Johannes Schindelin
2017-08-14 17:07 ` Stefan Beller
0 siblings, 1 reply; 4+ messages in thread
From: Johannes Schindelin @ 2017-08-14 16:05 UTC (permalink / raw
To: Dr.-Ing. Christoph Cullmann; +Cc: git
Hi Christoph,
On Fri, 11 Aug 2017, Dr.-Ing. Christoph Cullmann wrote:
> on Windows 64-bit, for a repository having a .pack file > 4GB I get
> during cloning:
The reason is Git's source code that over-uses the `unsigned long`
datatype.
In a nearby-thread, an underappreciated effort by Martin Koegler is
underway to get the ball rolling in getting it fixed. Maybe you can help
making Martin a lot more welcome on the Git mailing list, and maybe even
help getting his patches reviewed and integrated?
Ciao,
Johannes
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Bug with corruption on clone/fsck/... with large packs + 64-bit Windows, problem with usage of "long" datatype for sizes/offsets?
2017-08-14 16:05 ` Johannes Schindelin
@ 2017-08-14 17:07 ` Stefan Beller
2017-08-14 18:57 ` Junio C Hamano
0 siblings, 1 reply; 4+ messages in thread
From: Stefan Beller @ 2017-08-14 17:07 UTC (permalink / raw
To: Johannes Schindelin, martin.koegler
Cc: Dr.-Ing. Christoph Cullmann, git@vger.kernel.org
On Mon, Aug 14, 2017 at 9:05 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi Christoph,
>
> On Fri, 11 Aug 2017, Dr.-Ing. Christoph Cullmann wrote:
>
>> on Windows 64-bit, for a repository having a .pack file > 4GB I get
>> during cloning:
>
> The reason is Git's source code that over-uses the `unsigned long`
> datatype.
>
> In a nearby-thread, an underappreciated effort by Martin Koegler is
> underway to get the ball rolling in getting it fixed. Maybe you can help
> making Martin a lot more welcome on the Git mailing list, and maybe even
> help getting his patches reviewed and integrated?
'nearby' as in [1] ;-)
[1] https://public-inbox.org/git/1502527643-21944-1-git-send-email-martin@mail.zuhause/
I had the impression the review is going well there?
>
> Ciao,
> Johannes
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Bug with corruption on clone/fsck/... with large packs + 64-bit Windows, problem with usage of "long" datatype for sizes/offsets?
2017-08-14 17:07 ` Stefan Beller
@ 2017-08-14 18:57 ` Junio C Hamano
0 siblings, 0 replies; 4+ messages in thread
From: Junio C Hamano @ 2017-08-14 18:57 UTC (permalink / raw
To: Stefan Beller
Cc: Johannes Schindelin, martin.koegler, Dr.-Ing. Christoph Cullmann,
git@vger.kernel.org
Stefan Beller <sbeller@google.com> writes:
> On Mon, Aug 14, 2017 at 9:05 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>> Hi Christoph,
>>
>> On Fri, 11 Aug 2017, Dr.-Ing. Christoph Cullmann wrote:
>>
>>> on Windows 64-bit, for a repository having a .pack file > 4GB I get
>>> during cloning:
>>
>> The reason is Git's source code that over-uses the `unsigned long`
>> datatype.
>>
>> In a nearby-thread, an underappreciated effort by Martin Koegler is
>> underway to get the ball rolling in getting it fixed. Maybe you can help
>> making Martin a lot more welcome on the Git mailing list, and maybe even
>> help getting his patches reviewed and integrated?
>
> 'nearby' as in [1] ;-)
>
> [1] https://public-inbox.org/git/1502527643-21944-1-git-send-email-martin@mail.zuhause/
>
> I had the impression the review is going well there?
I do not know if it is "going well", but I do not agree with the
"underappreciated" bit at all. I find such a blanket statement
toxic and detrimental to the community.
It is true that many topics in flight are broken with a tree-wide
change that is presented as a single ball of wax. Unlike the
ongoing "struct object_id" effort, which also is tree-wide but tries
to find a step-wise refinement to reduce its impact on other topics,
it is harder to integrate such a change. But that does not have any
relation to how much the effort is appreciated.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-08-14 18:57 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-08-11 7:04 Bug with corruption on clone/fsck/... with large packs + 64-bit Windows, problem with usage of "long" datatype for sizes/offsets? Dr.-Ing. Christoph Cullmann
2017-08-14 16:05 ` Johannes Schindelin
2017-08-14 17:07 ` Stefan Beller
2017-08-14 18:57 ` Junio C Hamano
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).