Added a comment

1 files changed, 17 insertions, 0 deletions

diff --git a/doc/bugs/index_file_smaller_than_expected/comment_1_d87ae8c4d384d2ce6d1286b51bfdeba1._comment b/doc/bugs/index_file_smaller_than_expected/comment_1_d87ae8c4d384d2ce6d1286b51bfdeba1._comment
new file mode 100644
index 000000000..9cf0ce336
--- /dev/null
+++ b/doc/bugs/index_file_smaller_than_expected/comment_1_d87ae8c4d384d2ce6d1286b51bfdeba1._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.43"
+ subject="comment 1"
+ date="2014-01-14T21:12:19Z"
+ content="""
+It's unusual for git's index file to get corrupted or short like this. git writes to .git/index by first writing the new content to .git/index.lock, and then once it's written, renaming it. So if git is interrupted in the middle of a write, it doesn't leave the index file truncated. Of course, it's somewhat up to the OS's filesystem and buffering, and so I suppose if the system loses power at just the right time, and the filesystem does not journal data, this could happen. 
+
+Anyway, git-annex's assistant should be able to detect when the index file is corrupt, including too short, and fix it. When I try with a current version of git-annex, opening the webapp or starting the assistant results in the index file being automatically repaired, with this logged to .git/annex/daemon.log:
+
+<pre>
+fatal: index file smaller than expected
+[2014-01-14 16:58:11 JEST] SanityCheckerStartup: corrupt index file found at startup; removing and restaging
+</pre>
+
+However, it looks like it needs to do the same check for .git/annex/index. I was able to reproduce this bug by corrupting that file.
+"""]]