From f3c08f3e262c51cf3adac2a5f9501d22ce8c633b Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Tue, 14 Jan 2014 21:12:19 +0000 Subject: [PATCH] Added a comment --- ..._1_d87ae8c4d384d2ce6d1286b51bfdeba1._comment | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 doc/bugs/index_file_smaller_than_expected/comment_1_d87ae8c4d384d2ce6d1286b51bfdeba1._comment 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 0000000000..9cf0ce3365 --- /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: + +
+fatal: index file smaller than expected
+[2014-01-14 16:58:11 JEST] SanityCheckerStartup: corrupt index file found at startup; removing and restaging
+
+ +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. +"""]]