Re: [HELP] Corrupted repository

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 21, 2013, 19:00 UTC
Message-ID: <7vzjujl267.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALkWK0mTZqtGFp-BW9XBjX4Cm2hCZ1=P5M0a4cMBuE0v__LpZw@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

Show 15 quoted lines

> Junio C Hamano wrote:
>>>   $ ~/src/git
>>>   error: object file
>>> .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
>>>   error: object file
>>> .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
>>>   fatal: loose object 8e6a6dda24b017915449897fcc1353a9b848fd2f (stored
>>> in .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f) is corrupt
>>
>> So fsync() and close() thought that the filesystem stored this loose
>> object safely, but it turns out that the data is not on disk.
>
> Where should I start digging if I want to fix this?  Actually you just
> need to tell me how to build reduced-case corruptions to test: I can
> trace and figure out the rest.

That is a trip in the kernel source, isn't it? I cannot be your guide there.

Show 30 quoted lines

>
>>>   artagnon|remote-cruft*+:~/src/git$ git prune
>>>   artagnon|remote-cruft*+:~/src/git$ git status
>>>   fatal: bad object HEAD
>>>   fatal: bad object HEAD
>>
>> And the value in the HEAD was???
>
> ref: refs/heads/remote-cruft.  That's why I included my prompt :)
>
>>>   artagnon|remote-cruft*+:~/src/git$ git symbolic-ref HEAD refs/heads/master
>>>   artagnon|master*+=:~/src/git$ git status
>>>   ## master
>>>   MM Documentation/git-ls-remote.txt
>>>   MM remote.c
>>>   MM t/t5505-remote.sh
>>>   MM t/t5510-fetch.sh
>>>   MM t/t5515-fetch-merge-logic.sh
>>>   MM t/t5516-fetch-push.sh
>>>   ?? lib/
>>>   ?? outgoing/
>>>
>>> That status is completely bogus, by the way.
>>
>> ... which may suggest that your index file may have been corrupted
>> on the filesystem.
>
> Yeah, my question pertains to why is the index half-corrupted.  Is
> there no checksum to say "index corrupted; do not display bogus
> nonsense"?

Another possibility is perhaps the objects that are referred to by the index were missing or unreadable, and the index weren't.

Show 15 quoted lines

>
>>>   artagnon|master*+=:~/src/git$ git checkout remote-cruft
>>>   fatal: reference is not a tree: remote-cruft
>>>   artagnon|master=:~/src/git$ git reflog
>>>   21ff915 HEAD@{10 minutes ago}: rebase -i (finish): returning to
>>> refs/heads/remote-cruft
>>>
>>> What happened to the rest of my reflog?!
>>
>> On the filesystem known to not record the last consistent state of
>> the repository, the answer to that question may be rather obvious,
>> no?
>
> I didn't understand.  What does .git/logs/HEAD have to do with any of
> this?  Why is it truncated?

Explain why .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f was truncated to yourself, and the same explanation would apply to the .git/logs/HEAD file, I think.

> This was mainly a learning exercise for me: I wanted to see how good
> git was at working with corrupted repositories.

You could have just asked ;-).

A tl;dr is that we _trust_ our refs and everything reachable from them has to be complete. If that is not the case, things will not work, and it is not a priority to add workarounds in the normal codepath to slow things down.

That does not forbid an addition of "git recover-corrupted-repo" command, whose "assume everything might be broken" code is not shared with the fastpath of other commands.