[[!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.
"""]]