From b2323b9600e80deb98c767154fde1c627f4ce37d Mon Sep 17 00:00:00 2001 From: eigengrau Date: Thu, 11 Jun 2015 15:12:24 +0000 Subject: [PATCH] Added a comment --- .../comment_3_fa94d1b008a6c1663e40854edcd5504d._comment | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_3_fa94d1b008a6c1663e40854edcd5504d._comment diff --git a/doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_3_fa94d1b008a6c1663e40854edcd5504d._comment b/doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_3_fa94d1b008a6c1663e40854edcd5504d._comment new file mode 100644 index 0000000000..6fbc820f8d --- /dev/null +++ b/doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_3_fa94d1b008a6c1663e40854edcd5504d._comment @@ -0,0 +1,9 @@ +[[!comment format=mdwn + username="eigengrau" + subject="comment 3" + date="2015-06-11T15:12:23Z" + content=""" +Thanks! FWIW I didn’t have any hard kernel lockups recently. I figure git replaces the index file atomically, and only after all objects have been written to the store? I guess a userland crash couldn’t be the cause either, in that case? + +What happens when you manually run git gc at an inopportune moment, seeing that it probably doesn’t know about the secondary index? In the logs, I saw mention of locks on individual refs. Is the whole repository also locked down when git-annex commits something, or could it happen that a manual git gc prunes away objects added by git-annex before it had a chance to write the tree and commit it to a ref? +"""]]