followup for gleachkr

1 files changed, 32 insertions, 0 deletions

diff --git a/doc/bugs/inAnnex_check_failed_repeatedly_for_present_content_v6/comment_2_5e37bcb145880fe6074995f17c5aa7c3._comment b/doc/bugs/inAnnex_check_failed_repeatedly_for_present_content_v6/comment_2_5e37bcb145880fe6074995f17c5aa7c3._comment
new file mode 100644
index 000000000..94bada599
--- /dev/null
+++ b/doc/bugs/inAnnex_check_failed_repeatedly_for_present_content_v6/comment_2_5e37bcb145880fe6074995f17c5aa7c3._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-09-16T14:54:49Z"
+ content="""
+The .dump that shows the file is in the "content" table but
+not the "associated" table seems to confirm my hypothesis.
+
+Aha -- I was able to replicate having "content" but no "associated" in the
+keys database, by first using `git annex add` on a file, then `git annex
+unlock`, then `git annex lock`. Any chance this is what you did? (Perhaps
+some of those commits that git log shows were the locking/unlocking; if you
+`git show` the commits and see that the mode of the file has changed, that
+would confirm it.)
+
+I've still not quite managed to replicate the problem, because the cached
+inodes were still right. Tried moving the file away to another repo, but
+it then removed the cached inodes and so avoided the problem.
+
+Very interesting about the second file with `git annex get` and `git annex
+fsck` behaving differently. Does the file 'Car Seat Headrest/Teens of Denial/01 Fill in the Blank.m4a'
+still exist in your git repository?
+
+Is annex.thin set in .git/config?
+
+----
+
+I probably have enough information to move on to getting your repository
+fixed so you can stop being bothered by the problem at least. I think you
+could probably move .git/annex/keys/db out of the way, and run `git annex
+lock` followed by `git annex fsck` to get into a non-broken state.
+"""]]