{"thread":{"id":"34241","subject":"[HELP] Corrupted repository","startedAt":"2013-06-21T10:49:20Z","lastAt":"2013-06-23T17:48:17Z","messageCount":6,"participants":["Ramkumar Ramachandra","Junio C Hamano","Matthieu Moy"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"221573","messageId":"CALkWK0mQj+x3bxbxWKuwpeMj8E8bfvyK-c2bAWna6a9Xe=nBOQ@mail.gmail.com","threadId":"34241","inReplyTo":null,"subject":"[HELP] Corrupted repository","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-21T10:49:20Z","receivedAt":"2013-06-21T10:49:20Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi,\n\nUntil now, my interest in corrupted repositories has been very\nlimited.  Just now, the power went out for a second and my UPS failed\nme.  As a result, my ~/src/git is completely borked.  For your\namusement, here's a quick session showing me bumbling around:\n\n  $ ~/src/git\n  error: object file\n.git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty\n  error: object file\n.git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty\n  fatal: loose object 8e6a6dda24b017915449897fcc1353a9b848fd2f (stored\nin .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f) is corrupt\n  artagnon|remote-cruft*+:~/src/git$ rm\n.git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f\n  artagnon|remote-cruft*+:~/src/git$ git prune\n  artagnon|remote-cruft*+:~/src/git$ git status\n  fatal: bad object HEAD\n  fatal: bad object HEAD\n  artagnon|remote-cruft*+:~/src/git$ git symbolic-ref HEAD refs/heads/master\n  artagnon|master*+=:~/src/git$ git status\n  ## master\n  MM Documentation/git-ls-remote.txt\n  MM remote.c\n  MM t/t5505-remote.sh\n  MM t/t5510-fetch.sh\n  MM t/t5515-fetch-merge-logic.sh\n  MM t/t5516-fetch-push.sh\n  ?? lib/\n  ?? outgoing/\n\nThat status is completely bogus, by the way.\n\n  artagnon|master*+=:~/src/git$ git reset --hard\n  artagnon|master*+=:~/src/git$ git checkout remote-cruft\n  fatal: reference is not a tree: remote-cruft\n  artagnon|master=:~/src/git$ git reflog\n  21ff915 HEAD@{10 minutes ago}: rebase -i (finish): returning to\nrefs/heads/remote-cruft\n\nWhat happened to the rest of my reflog?!  Okay, I give up.  Let's go\nback to what's present on Github.  I push often, so it's not a\nproblem.\n\n  artagnon|master=:~/src/git$ git branch -D remote-cruft\n  error: Couldn't look up commit object for 'refs/heads/remote-cruft'\n  artagnon|master=:~/src/git$ rm .git/refs/heads/remote-cruft\n  artagnon|master=:~/src/git$ git checkout -b remote-cruft\n  Switched to a new branch 'remote-cruft'\n\nHuh?  What happened to my upstream?\n\n  artagnon|remote-cruft:~/src/git$ git branch -u ram/remote-cruft\n  warning: ignoring broken ref refs/remotes/ram/remote-cruft.\n\nFine, let's fetch.\n\n  artagnon|remote-cruft:~/src/git$ git fetch ram\n  remote: Counting objects: 101, done.\n  remote: Compressing objects: 100% (24/24), done.\n  remote: Total 92 (delta 78), reused 82 (delta 68)\n  error: object file\n.git/objects/08/2b069c11e8d4f372b963b038cbf5b71a676ef6 is empty\n  fatal: loose object 082b069c11e8d4f372b963b038cbf5b71a676ef6 (stored\nin .git/objects/08/2b069c11e8d4f372b963b038cbf5b71a676ef6) is corrupt\n  fatal: unpack-objects failed\n\nFine, let's run an fsck and get rid of all the corrupted objects.\n\n  $ git fsck\n  error: object file\n.git/objects/08/2b069c11e8d4f372b963b038cbf5b71a676ef6 is empty\n  error: object file\n.git/objects/08/2b069c11e8d4f372b963b038cbf5b71a676ef6 is empty\n  fatal: loose object 082b069c11e8d4f372b963b038cbf5b71a676ef6 (stored\nin .git/objects/08/2b069c11e8d4f372b963b038cbf5b71a676ef6) is corrupt\n  artagnon|remote-cruft:~/src/git$ rm\n.git/objects/08/2b069c11e8d4f372b963b038cbf5b71a676ef6\n  artagnon|remote-cruft:~/src/git$ git repack\n  artagnon|remote-cruft:~/src/git$ git fetch ram\n  remote: Counting objects: 101, done.\n  remote: Compressing objects: 100% (24/24), done.\n  remote: Total 92 (delta 78), reused 82 (delta 68)\n  Unpacking objects: 100% (92/92), done.\n  error: object file\n.git/objects/64/fa33d706658278b871a6e2ca66694efcadacca is empty\n  fatal: loose object 64fa33d706658278b871a6e2ca66694efcadacca (stored\nin .git/objects/64/fa33d706658278b871a6e2ca66694efcadacca) is corrupt\n  error: github.com:artagnon/git did not send all necessary objects\n\nFine, my packfiles are corrupt.  Let's unpack-objects by hand.\n\n  artagnon|remote-cruft:~/src/git$ mv .git/objects/pack .git/objects/pack.old\n  artagnon|remote-cruft+:~/src/git$ for i in\n.git/objects/pack.old/*.pack; do git unpack-objects -r <$i; done\n  artagnon|remote-cruft:~/src/git$ git fetch ram\n  remote: Counting objects: 101, done.\n  remote: Compressing objects: 100% (24/24), done.\n  remote: Total 92 (delta 78), reused 82 (delta 68)\n  Unpacking objects: 100% (92/92), done.\n  error: object file\n.git/objects/64/fa33d706658278b871a6e2ca66694efcadacca is empty\n  fatal: loose object 64fa33d706658278b871a6e2ca66694efcadacca (stored\nin .git/objects/64/fa33d706658278b871a6e2ca66694efcadacca) is corrupt\n  error: github.com:artagnon/git did not send all necessary objects\n\n  Auto packing the repository for optimum performance. You may also\n  run \"git gc\" manually. See \"git help gc\" for more information.\n  error: bad ref for refs/remotes/ram/remote-cruft\n  error: bad ref for refs/remotes/ram/remote-cruft\n  Counting objects: 161917, done.\n  Delta compression using up to 8 threads.\n  Compressing objects: 100% (159963/159963), done.\n  Writing objects: 100% (161917/161917), done.\n  Total 161917 (delta 117725), reused 0 (delta 0)\n  Removing duplicate objects: 100% (256/256), done.\n  error: bad ref for refs/remotes/ram/remote-cruft\n  Checking connectivity: 161917, done.\n  warning: There are too many unreachable loose objects; run 'git\nprune' to remove them.\n\nI'm assuming it just went back and fetched everything the second time.\n Why didn't it do that in the first place?\n\n  artagnon|remote-cruft:~/src/git$ git log ram/remote-cruft\n  warning: ignoring broken ref refs/remotes/ram/remote-cruft.\n\nNow what?  Why didn't the fetch update this ref?\n\n  artagnon|remote-cruft:~/src/git$ rm .git/refs/remotes/ram/remote-cruft\n  artagnon|remote-cruft:~/src/git$ git fetach ram\n  remote: Counting objects: 101, done.\n  remote: Compressing objects: 100% (24/24), done.\n  remote: Total 92 (delta 78), reused 82 (delta 68)\n  Unpacking objects: 100% (92/92), done.\n  From github.com:artagnon/git\n   * [new branch]      remote-cruft -> ram/remote-cruft\n   * [new branch]      upstream-fix -> ram/upstream-fix\n\nYes!  Everything finally works.\n\nWas I being stupid, or is fixing corrupted repositories really this\nnon-trivial?  Comments appreciated.\n\nThanks.\n"},{"id":"221607","messageId":"7v7ghno2lz.fsf@alter.siamese.dyndns.org","threadId":"34241","inReplyTo":"CALkWK0mQj+x3bxbxWKuwpeMj8E8bfvyK-c2bAWna6a9Xe=nBOQ@mail.gmail.com","subject":"Re: [HELP] Corrupted repository","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-21T16:22:32Z","receivedAt":"2013-06-21T16:22:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n>   $ ~/src/git\n>   error: object file\n> .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty\n>   error: object file\n> .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty\n>   fatal: loose object 8e6a6dda24b017915449897fcc1353a9b848fd2f (stored\n> in .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f) is corrupt\n\nSo fsync() and close() thought that the filesystem stored this loose\nobject safely, but it turns out that the data is not on disk.\n\n>   artagnon|remote-cruft*+:~/src/git$ rm\n> .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f\n\nAs you know it is empty, removing (as long as you do not forget what\nthe object name was, which may later become useful when untangling\nthe mess further) does not hurt very much.\n\n>   artagnon|remote-cruft*+:~/src/git$ git prune\n>   artagnon|remote-cruft*+:~/src/git$ git status\n>   fatal: bad object HEAD\n>   fatal: bad object HEAD\n\nAnd the value in the HEAD was???\n\n>   artagnon|remote-cruft*+:~/src/git$ git symbolic-ref HEAD refs/heads/master\n>   artagnon|master*+=:~/src/git$ git status\n>   ## master\n>   MM Documentation/git-ls-remote.txt\n>   MM remote.c\n>   MM t/t5505-remote.sh\n>   MM t/t5510-fetch.sh\n>   MM t/t5515-fetch-merge-logic.sh\n>   MM t/t5516-fetch-push.sh\n>   ?? lib/\n>   ?? outgoing/\n>\n> That status is completely bogus, by the way.\n\n... which may suggest that your index file may have been corrupted\non the filesystem.\n\n>   artagnon|master*+=:~/src/git$ git reset --hard\n\n... and using that known-to-be-corrupt index, the working tree state\nis discarded.\n\n>   artagnon|master*+=:~/src/git$ git checkout remote-cruft\n>   fatal: reference is not a tree: remote-cruft\n>   artagnon|master=:~/src/git$ git reflog\n>   21ff915 HEAD@{10 minutes ago}: rebase -i (finish): returning to\n> refs/heads/remote-cruft\n>\n> What happened to the rest of my reflog?!\n\nOn the filesystem known to not record the last consistent state of\nthe repository, the answer to that question may be rather obvious,\nno?\n\n>   artagnon|master=:~/src/git$ git branch -D remote-cruft\n>   error: Couldn't look up commit object for 'refs/heads/remote-cruft'\n\nThe command would want to report what was at the tip, so it is\nunderstandable it may want to look up that commit before removing\nthe ref.\n\n>   artagnon|master=:~/src/git$ rm .git/refs/heads/remote-cruft\n>   artagnon|master=:~/src/git$ git checkout -b remote-cruft\n>   Switched to a new branch 'remote-cruft'\n>\n> Huh?  What happened to my upstream?\n>\n>   artagnon|remote-cruft:~/src/git$ git branch -u ram/remote-cruft\n>   warning: ignoring broken ref refs/remotes/ram/remote-cruft.\n\nSo remotes/ram/remote-cruft is also broken.\n\n> Fine, let's fetch.\n\nWhy?\n\n\"fetch\" walks the ancestry graph on both ends to minimize transfers.\nIt's not something you would expect to work when you know refs at\nyour end does not even record what you do have.  It _may_ appear to\nwork if your refs are intact but you are missing objects, as they\nwill not be transferred again from the good copy if you let your\nrepository's ref claim that you have _all_ objects behind it when\nyou actually don't.\n\nWhat would have been a better starting point to untangle is to make\na separate clone, pretending as if this repository did not even\nexist, and copy the resulting packfile into this repository.  That\nwould at least give you a known good copies of objects that you\nalready have pushed out.\n\nAnd the next step would have been (without doing any of the above\n\"remove this branch, recreate this one anew\") to compare the tips\nof refs in this broken repository and the clone.  The same ones you\ncan trust, and different ones you dig further.\n\n> Was I being stupid, or is fixing corrupted repositories really this\n> non-trivial?  Comments appreciated.\n\nI think \"Let's fetch first\" was the step that took you in a wrong\ndirection that requires unnecessary work.\n"},{"id":"221611","messageId":"CALkWK0mTZqtGFp-BW9XBjX4Cm2hCZ1=P5M0a4cMBuE0v__LpZw@mail.gmail.com","threadId":"34241","inReplyTo":"7v7ghno2lz.fsf@alter.siamese.dyndns.org","subject":"Re: [HELP] Corrupted repository","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-21T16:44:06Z","receivedAt":"2013-06-21T16:44:06Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n>>   $ ~/src/git\n>>   error: object file\n>> .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty\n>>   error: object file\n>> .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty\n>>   fatal: loose object 8e6a6dda24b017915449897fcc1353a9b848fd2f (stored\n>> in .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f) is corrupt\n>\n> So fsync() and close() thought that the filesystem stored this loose\n> object safely, but it turns out that the data is not on disk.\n\nWhere should I start digging if I want to fix this?  Actually you just\nneed to tell me how to build reduced-case corruptions to test: I can\ntrace and figure out the rest.\n\n>>   artagnon|remote-cruft*+:~/src/git$ git prune\n>>   artagnon|remote-cruft*+:~/src/git$ git status\n>>   fatal: bad object HEAD\n>>   fatal: bad object HEAD\n>\n> And the value in the HEAD was???\n\nref: refs/heads/remote-cruft.  That's why I included my prompt :)\n\n>>   artagnon|remote-cruft*+:~/src/git$ git symbolic-ref HEAD refs/heads/master\n>>   artagnon|master*+=:~/src/git$ git status\n>>   ## master\n>>   MM Documentation/git-ls-remote.txt\n>>   MM remote.c\n>>   MM t/t5505-remote.sh\n>>   MM t/t5510-fetch.sh\n>>   MM t/t5515-fetch-merge-logic.sh\n>>   MM t/t5516-fetch-push.sh\n>>   ?? lib/\n>>   ?? outgoing/\n>>\n>> That status is completely bogus, by the way.\n>\n> ... which may suggest that your index file may have been corrupted\n> on the filesystem.\n\nYeah, my question pertains to why is the index half-corrupted.  Is\nthere no checksum to say \"index corrupted; do not display bogus\nnonsense\"?\n\n>>   artagnon|master*+=:~/src/git$ git checkout remote-cruft\n>>   fatal: reference is not a tree: remote-cruft\n>>   artagnon|master=:~/src/git$ git reflog\n>>   21ff915 HEAD@{10 minutes ago}: rebase -i (finish): returning to\n>> refs/heads/remote-cruft\n>>\n>> What happened to the rest of my reflog?!\n>\n> On the filesystem known to not record the last consistent state of\n> the repository, the answer to that question may be rather obvious,\n> no?\n\nI didn't understand.  What does .git/logs/HEAD have to do with any of\nthis?  Why is it truncated?\n\n>>   artagnon|master=:~/src/git$ git branch -D remote-cruft\n>>   error: Couldn't look up commit object for 'refs/heads/remote-cruft'\n>\n> The command would want to report what was at the tip, so it is\n> understandable it may want to look up that commit before removing\n> the ref.\n\nI would have expected it to display a warning and remove the ref\nanyway.  Or error out, and override with a force-flag?\n\n>> Fine, let's fetch.\n>\n> Why?\n>\n> \"fetch\" walks the ancestry graph on both ends to minimize transfers.\n> It's not something you would expect to work when you know refs at\n> your end does not even record what you do have.  It _may_ appear to\n> work if your refs are intact but you are missing objects, as they\n> will not be transferred again from the good copy if you let your\n> repository's ref claim that you have _all_ objects behind it when\n> you actually don't.\n\nRight.  I expected it to figure out that I have a broken history and\nfetch everything (which is what happened the second time, no?).\n\n> What would have been a better starting point to untangle is to make\n> a separate clone, pretending as if this repository did not even\n> exist, and copy the resulting packfile into this repository.  That\n> would at least give you a known good copies of objects that you\n> already have pushed out.\n\nYeah, I deliberately avoided doing that: apart from the config and\nrefs, I had no real unpushed work in ~/src/git anyway (I push _very_\nfrequently, which explains my \"resolve HEAD early in current\" patch).\nThe most important part of what I did was running unpack-objects by\nhand: that fixed everything.  I shouldn't have had to run that by hand\nthough: why isn't there an in-built way to unpack everything, remove\ncorruptions, and repack the good stuff?\n\n> And the next step would have been (without doing any of the above\n> \"remove this branch, recreate this one anew\") to compare the tips\n> of refs in this broken repository and the clone.  The same ones you\n> can trust, and different ones you dig further.\n\nRight.  I didn't have local data in this case, so I didn't bother.\n\n>> Was I being stupid, or is fixing corrupted repositories really this\n>> non-trivial?  Comments appreciated.\n>\n> I think \"Let's fetch first\" was the step that took you in a wrong\n> direction that requires unnecessary work.\n\nThis was mainly a learning exercise for me: I wanted to see how good\ngit was at working with corrupted repositories.  I did my surgery\nfairly quickly, and avoided large network transfers (I have a slow\nconnection).\n"},{"id":"221634","messageId":"7vzjujl267.fsf@alter.siamese.dyndns.org","threadId":"34241","inReplyTo":"CALkWK0mTZqtGFp-BW9XBjX4Cm2hCZ1=P5M0a4cMBuE0v__LpZw@mail.gmail.com","subject":"Re: [HELP] Corrupted repository","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-21T19:00:16Z","receivedAt":"2013-06-21T19:00:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> Junio C Hamano wrote:\n>>>   $ ~/src/git\n>>>   error: object file\n>>> .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty\n>>>   error: object file\n>>> .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty\n>>>   fatal: loose object 8e6a6dda24b017915449897fcc1353a9b848fd2f (stored\n>>> in .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f) is corrupt\n>>\n>> So fsync() and close() thought that the filesystem stored this loose\n>> object safely, but it turns out that the data is not on disk.\n>\n> Where should I start digging if I want to fix this?  Actually you just\n> need to tell me how to build reduced-case corruptions to test: I can\n> trace and figure out the rest.\n\nThat is a trip in the kernel source, isn't it?  I cannot be your\nguide there.\n\n>\n>>>   artagnon|remote-cruft*+:~/src/git$ git prune\n>>>   artagnon|remote-cruft*+:~/src/git$ git status\n>>>   fatal: bad object HEAD\n>>>   fatal: bad object HEAD\n>>\n>> And the value in the HEAD was???\n>\n> ref: refs/heads/remote-cruft.  That's why I included my prompt :)\n>\n>>>   artagnon|remote-cruft*+:~/src/git$ git symbolic-ref HEAD refs/heads/master\n>>>   artagnon|master*+=:~/src/git$ git status\n>>>   ## master\n>>>   MM Documentation/git-ls-remote.txt\n>>>   MM remote.c\n>>>   MM t/t5505-remote.sh\n>>>   MM t/t5510-fetch.sh\n>>>   MM t/t5515-fetch-merge-logic.sh\n>>>   MM t/t5516-fetch-push.sh\n>>>   ?? lib/\n>>>   ?? outgoing/\n>>>\n>>> That status is completely bogus, by the way.\n>>\n>> ... which may suggest that your index file may have been corrupted\n>> on the filesystem.\n>\n> Yeah, my question pertains to why is the index half-corrupted.  Is\n> there no checksum to say \"index corrupted; do not display bogus\n> nonsense\"?\n\nAnother possibility is perhaps the objects that are referred to by\nthe index were missing or unreadable, and the index weren't.\n\n>\n>>>   artagnon|master*+=:~/src/git$ git checkout remote-cruft\n>>>   fatal: reference is not a tree: remote-cruft\n>>>   artagnon|master=:~/src/git$ git reflog\n>>>   21ff915 HEAD@{10 minutes ago}: rebase -i (finish): returning to\n>>> refs/heads/remote-cruft\n>>>\n>>> What happened to the rest of my reflog?!\n>>\n>> On the filesystem known to not record the last consistent state of\n>> the repository, the answer to that question may be rather obvious,\n>> no?\n>\n> I didn't understand.  What does .git/logs/HEAD have to do with any of\n> this?  Why is it truncated?\n\nExplain why .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f\nwas truncated to yourself, and the same explanation would apply to\nthe .git/logs/HEAD file, I think.\n\n> This was mainly a learning exercise for me: I wanted to see how good\n> git was at working with corrupted repositories.\n\nYou could have just asked ;-).\n\nA tl;dr is that we _trust_ our refs and everything reachable from\nthem has to be complete.  If that is not the case, things will not\nwork, and it is not a priority to add workarounds in the normal\ncodepath to slow things down.\n\nThat does not forbid an addition of \"git recover-corrupted-repo\"\ncommand, whose \"assume everything might be broken\" code is not\nshared with the fastpath of other commands.\n"},{"id":"221636","messageId":"CALkWK0kLmdbooWUw-x+TBk-fB_XDFQzyu6Q8yb1Prsgi3FD67A@mail.gmail.com","threadId":"34241","inReplyTo":"7vzjujl267.fsf@alter.siamese.dyndns.org","subject":"Re: [HELP] Corrupted repository","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-21T19:15:47Z","receivedAt":"2013-06-21T19:15:47Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> A tl;dr is that we _trust_ our refs and everything reachable from\n> them has to be complete.  If that is not the case, things will not\n> work, and it is not a priority to add workarounds in the normal\n> codepath to slow things down.\n\nMakes sense.\n\n> That does not forbid an addition of \"git recover-corrupted-repo\"\n> command, whose \"assume everything might be broken\" code is not\n> shared with the fastpath of other commands.\n\nI'm not looking for a kitchen-sink command: I'm looking for a\nwell-documented toolset to precisely fix corruptions.  We have some\ncorruption tests in our testsuite already: I think I'll start digging\nthere.\n\nThanks.\n"},{"id":"221728","messageId":"vpqwqpk4t26.fsf@anie.imag.fr","threadId":"34241","inReplyTo":"7vzjujl267.fsf@alter.siamese.dyndns.org","subject":"Re: [HELP] Corrupted repository","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-06-23T17:48:17Z","receivedAt":"2013-06-23T17:48:17Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Ramkumar Ramachandra <artagnon@gmail.com> writes:\n>\n>> Junio C Hamano wrote:\n>>>>   $ ~/src/git\n>>>>   error: object file\n>>>> .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty\n>>>>   error: object file\n>>>> .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty\n>>>>   fatal: loose object 8e6a6dda24b017915449897fcc1353a9b848fd2f (stored\n>>>> in .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f) is corrupt\n>>>\n>>> So fsync() and close() thought that the filesystem stored this loose\n>>> object safely, but it turns out that the data is not on disk.\n>>\n>> Where should I start digging if I want to fix this?  Actually you just\n>> need to tell me how to build reduced-case corruptions to test: I can\n>> trace and figure out the rest.\n>\n> That is a trip in the kernel source, isn't it?  I cannot be your\n> guide there.\n\nNot necessarily. AFAICT, Git won't fsync object files by default, but\ndoes for pack files (to make sure the pack is written before unlinking\nthe object files being packed):\n\n       core.fsyncobjectfiles\n           This boolean will enable fsync() when writing object files.\n\n           This is a total waste of time and effort on a filesystem that\n           orders data writes properly, but can be useful for\n           filesystems that do not use journalling (traditional UNIX\n           filesystems) or that only journal metadata and not file\n           contents (OS X’s HFS+, or Linux ext3 with \"data=writeback\").\n\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"}]}