From: Linus Torvalds <torvalds@linux-foundation.org>
To: Alexander Litvinov <litvinov2004@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: My git repo is broken, how to fix it ?
Date: Mon, 19 Mar 2007 22:34:10 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.64.0703192212280.6730@woody.linux-foundation.org> (raw)
In-Reply-To: <200703201013.39169.litvinov2004@gmail.com>
On Tue, 20 Mar 2007, Alexander Litvinov wrote:
>
> Actualy, I have packed that objects already, so fsck warn me:
> $ git fsck --full
> error: packed 8edc906985f00cf27180b1d9d4c3217ffd1896f8 from .git/objects/pack/pack-abc5cbabfc05c213e50c43ea07f43158bf1de236.pack is corrupt
> error: packed f6aca57bb30a12e9ac5d71558e0b6052d6fb67a8 from .git/objects/pack/pack-abc5cbabfc05c213e50c43ea07f43158bf1de236.pack is corrupt
> sha1 mismatch 8edc906985f00cf27180b1d9d4c3217ffd1896f8
> sha1 mismatch f6aca57bb30a12e9ac5d71558e0b6052d6fb67a8
Ok, this is different from what I expected.
Since your pack-file seems to pass its own internal SHA1 checks, it means
that it was likely corrupt already when it was written out in the pack.
What's interesting is that it seems to unpack, but then the SHA1 of the
unpacked object doesn't match.
The reason I say that's interesting is that it would seem to mean that the
zlib CRC/adler check didn't trigger - which probably means that the object
was corrupted *before* it was compressed (but after it was originally
SHA1-summed), or the compression itself was corrupting (eg a libz
problem).
And since the SHA1 of the pack-file matches, the thing was apparently
also written out "correctly" after compression (but by that "correctly" I
obviously mean that the *corrupted* data was written out).
Sadly, by the time it's in a pack-file, it is *really* hard to figure out
what went wrong: I see your unpacked data, but it's really the packed raw
objects that I wanted to look at, in case there would be some pattern in
the actual corruption (the corruption will then result in random crud when
actually unpacking, which is why the unpacked data isn't that interesting,
simple because there's no pattern left to analyze - it got inflated to
bogus "data").
> I also use autocrlf feature:
> $ git config core.autocrlf
> true
I doubt autocrlf affects anything here, it's only used at checkin and
checkout time, and it wouldn't affect the raw internal git objects.
More interesting might be if you might be using any of the other flags
that actually affect internal git object packing: "use_legacy_headers" in
particular? If we have a bug there, that could be nasty.
But to really look at this we should probably add a "really_careful" flag
that actually re-verifies the SHA1 on read so that we'd catch these kinds
of corruptions early.
> This files are cpp code from our project and tham need to be private. Really.
Ok, no problem. I added back the git list (but not your attachments,
obviously) but as explained above, there is not a lot I can do with the
unpacked data, I'd like to see the actual "raw" stuff.
I'm hoping somebody has any ideas. We really *could* check the SHA1 on
each read (and slow down git a lot) and that would catch corruption much
faster and hopefully pinpoint it more quickly where exactly it happens.
But maybe somebody has some other smart idea?
Linus
next prev parent reply other threads:[~2007-03-20 5:34 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-28 4:36 My git repo is broken, how to fix it ? Alexander Litvinov
2007-02-28 4:57 ` Linus Torvalds
2007-02-28 11:54 ` Alexander Litvinov
2007-02-28 16:19 ` Linus Torvalds
2007-02-28 19:12 ` Alex Riesen
2007-03-19 13:32 ` Alexander Litvinov
2007-03-19 15:20 ` Linus Torvalds
[not found] ` <200703201013.39169.litvinov2004@gmail.com>
2007-03-20 5:34 ` Linus Torvalds [this message]
2007-03-20 6:55 ` Alexander Litvinov
2007-03-20 7:42 ` Junio C Hamano
2007-03-20 15:23 ` Nicolas Pitre
[not found] ` <Pine.LNX.4.64.0703200832150.6730@woody.linux-foundation.org>
[not found] ` <Pine.LNX.4.64.0703200836490.6730@woody.linux-foundation.org>
[not found] ` <200703210956.50018.litvinov2004@gmail.com>
2007-03-22 15:58 ` Linus Torvalds
2007-03-22 16:34 ` Nicolas Pitre
[not found] ` <200703211024.04740.litvinov2004@gmail.com>
2007-03-22 16:17 ` Linus Torvalds
2007-03-22 16:29 ` Linus Torvalds
2007-03-22 16:48 ` Linus Torvalds
2007-03-22 17:01 ` Nicolas Pitre
2007-03-22 17:10 ` Linus Torvalds
2007-03-22 17:28 ` Nicolas Pitre
2007-03-22 22:13 ` Jeff King
2007-03-23 0:25 ` Linus Torvalds
2007-03-23 0:42 ` Bill Lear
2007-03-23 0:51 ` Jeff King
2007-03-22 20:31 ` [PATCH] git-apply: Do not free the wrong buffer when we convert the data for writeout Junio C Hamano
2007-03-22 20:55 ` Linus Torvalds
2007-03-23 3:55 ` Alexander Litvinov
2007-03-23 3:40 ` My git repo is broken, how to fix it ? Alexander Litvinov
2007-03-22 17:12 ` Johannes Sixt
-- strict thread matches above, loose matches on Subject: below --
2021-06-06 17:27 B
2021-06-06 17:28 B
2021-12-25 8:30 Joseph Mitchell
2021-12-26 0:48 ` Lemuria
2023-05-29 18:57 ross thomas
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=Pine.LNX.4.64.0703192212280.6730@woody.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=git@vger.kernel.org \
--cc=litvinov2004@gmail.com \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).