mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

followup for gleachkr

Browse source
This commit is contained in:
Joey Hess 2017-09-16 11:26:00 -04:00
parent 97eacf3a7a
commit 260d1061cd
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 32 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

32
doc/bugs/inAnnex_check_failed_repeatedly_for_present_content_v6/comment_2_5e37bcb145880fe6074995f17c5aa7c3._comment Normal file
View file

@ -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.
"""]]