Please describe the problem.
"git status" returns a list of almost all files in the annex (located on a FAT32 device) with these messages:
git-annex: git status will show music/a.flac to be modified, since content availability has changed and git-annex was unable to update the index. This is only a cosmetic problem affecting git status; git add, git commit, etc won't be affected. To fix the git status display, you can run: git update-index -q --refresh music/a.flac
... (a lot of similar messages for +30000 files)
and then a new list of messages:
...
git-annex: thread blocked indefinitely in an MVar operation
error: external filter 'git-annex smudge --clean %f' failed 1
error: external filter 'git-annex smudge --clean %f' failed
git-annex: thread blocked indefinitely in an MVar operation
error: external filter 'git-annex smudge --clean %f' failed 1
error: external filter 'git-annex smudge --clean %f' failed
...
refresh index: 81% (30495/37394)
What steps will reproduce the problem?
What version of git-annex are you using? On what operating system?
debian sid, git-annex version: 7.20190129
Please provide any additional information below.
# If you can, paste a complete transcript of the problem occurring here.
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
# End of transcript or log.
Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
I think this got fixed by 195508fc6541b8f03b78e2ae457422308fc8d9e2. done --Joey
Does this still happen with version 7.20190220?
I take it you're using v7 mode with unlocked files?
That's right, I'm using v7 mode with unlocked files.
With 7.20190220-g9d7663432, I now get:
The command above finally ended. Then
git annex sync
returns:I think I found the problem: my filesystem is probably full after all, I just noticed that
annex.thin
isn't supported on FAT and that the files got duplicated :-(. Bad news for me and my perfect rockbox player backed up with git-annex!Ok, it makes sense that sqlite would crash creating a DB if the disk was full.
I hope that the earlier Mvar error was the same problem, just a different handling of the exception in that version. Or something similar failing on full disk.
annex.thin needing hard links is a limitation that may one day be lifted, see ?annex.thin without hardlinks