Already fixed in git head.

You should reat the dirct mode page.

In short, use git-annex sync as a replacement for git commit.

Ok, I tried it using GIT_DIR and GIT_WORK_TREE:

Current directory is ~/git-annex, ./work exists and is populated with some files.

% GIT_DIR=~/git-annex/git GIT_WORK_TREE=~/git-annex/work git init
% GIT_DIR=~/git-annex/git GIT_WORK_TREE=~/git-annex/work git annex init "server"
% GIT_DIR=~/git-annex/git GIT_WORK_TREE=~/git-annex/work git annex direct
% GIT_DIR=~/git-annex/git GIT_WORK_TREE=~/git-annex/work git annex add .
[... file are addded ...]
% GIT_DIR=~/git-annex/git GIT_WORK_TREE=~/git-annex/work git annex sync
[... file are synced ...]

% git clone git remote
% cd remote
% git annex init "remote"
% git annex sync


% git annex get a.out
get a.out
  Unable to access these remotes: origin

  Try making some of these repositories available:
        ed208c9f-a963-4000-a505-c3fe9dab0042 -- server [origin]
failed
git-annex: get: 1 failed


% git annex whereis a.out
whereis a.out (1 copy)
        ed208c9f-a963-4000-a505-c3fe9dab0042 -- server [origin]
ok

The remote is of course available, it's all local.

What is still wrong?

Thanks, Florian

Some useful information has been shared here in this article - http://wordpress.semnaitik.com/2017/02/01/repair-sqlite-database/

Refer to the above article and learn how to repair SQLite database.

Thanks.

Look. What’s happening here? Reverse order. First, a file is saved and then assistant running on other machines makes a decision to remove it. Where does it come from?

``` commit cc61f6db3273c749ac2e4bdfb489457af919472c Author: Elzbieta Rus rus.elzbieta@gmail.com Date: Sat Sep 2 14:23:13 2017 +0200

git-annex in elzbietarus

Dokumenty/Przepisy/SERNIK NA ZIMNO.docx | 1 - 1 file changed, 1 deletion(-)

commit 30965f29f756f02ad5d617d6fd07ec7013e01226 Merge: d69d69901f ec07710223 Author: Robert Rus rusrob@poczta.onet.pl Date: Sat Sep 2 14:17:20 2017 +0200

Merge remote-tracking branch 'refs/remotes/origin/master'

commit d69d69901fc2a4c958077cfbf8b27f595465627c Author: Robert Rus rusrob@poczta.onet.pl Date: Sat Sep 2 14:17:17 2017 +0200

git-annex in robertrus-asus-1225c

Dokumenty/Przepisy/SERNIK NA ZIMNO.odt | 1 + 1 file changed, 1 insertion(+)

commit ec07710223770d1458de76004ec9baab5c20d508 Merge: a60c530e9b 1cb58f2783 Author: Robert Rus rusrob@poczta.onet.pl Date: Sat Sep 2 14:17:17 2017 +0200

Merge remote-tracking branch 'refs/remotes/origin/master'

commit 1e29dee284b5b9f4593cd7c0484c194ac2a9644c Merge: 1a36f09308 1cb58f2783 Author: Robert Rus rusrob@poczta.onet.pl Date: Sat Sep 2 14:17:16 2017 +0200

Merge remote-tracking branch 'refs/remotes/origin/master'

commit a60c530e9b167c17b625e66f42e7282a1e275703 Author: Robert Rus rusrob@poczta.onet.pl Date: Sat Sep 2 14:17:16 2017 +0200

git-annex in robertrus-acer

Dokumenty/Przepisy/SERNIK NA ZIMNO.odt | 1 + 1 file changed, 1 insertion(+)

commit 1a36f09308c4134646b7074f2e827c909ee7033a Author: Robert Rus rusrob@poczta.onet.pl Date: Sat Sep 2 14:17:14 2017 +0200

git-annex in robertrus-asus-1225c

Dokumenty/Przepisy/SERNIK NA ZIMNO.odt | 1 - 1 file changed, 1 deletion(-)

commit 1cb58f2783485e83d369ab9acb41f7e83cc3314c Author: Mikolaj Rus mikolaj.rus6@gmail.com Date: Sat Sep 2 14:17:12 2017 +0200

git-annex in mikolajrus

Dokumenty/Przepisy/SERNIK NA ZIMNO.odt | 1 + 1 file changed, 1 insertion(+)

commit 3542add42a050c5331cbfa67bffee38a05ce6bc6 Author: Mikolaj Rus mikolaj.rus6@gmail.com Date: Sat Sep 2 14:17:11 2017 +0200

git-annex in mikolajrus

Dokumenty/Przepisy/SERNIK NA ZIMNO.odt | 1 - 1 file changed, 1 deletion(-)

commit 956243cab7b865f9e633f51d4376154a3478210a Author: Elzbieta Rus rus.elzbieta@gmail.com Date: Sat Sep 2 14:17:00 2017 +0200

git-annex in elzbietarus

Dokumenty/Przepisy/SERNIK NA ZIMNO.odt | 1 + 1 file changed, 1 insertion(+) ```

Removing the db and running fsck seems to have fixed the problem. I really appreciate it. I do think that I unlocked and then re-locked some of the affected files, but I think only after I noticed that they were behaving strangely---in particular, I think I only did this with the affected files that were not fscking correctly (and this was before I realized they were not fscking correctly), not with e.g. the Car Seat Headrest song.

I didn't get the chance to fill in the "Have you had any luck using git-annex before" part of the standard bug report, so I thought I should add that here: Yes, I've used git-annex regularly for quite a while now. It's an inspiring piece of open-source software. I'm always finding new things it can do. Thank you for creating it, and thanks for your help with this issue!

Actually, you should git annex lock before moving the database out of the way, otherwise it might be confused. So:

1. git annex lock
2. move keys/db to a safe backup location
3. git annex fsck

Right, just back up the keys/db just in case, and you need to fsck at least any files that are not locked (to repopulate the keys/db for those), so safest is to fsck the whole repository..

Is it possible that you've run git annex unlock / git annex lock on some of the affected files in the past?

The second file (01 Fill in the Blank.m4a) does still exist, although annex get always re-retrieves it. annx.thin is not set. Here's the git config, minus remotes:

[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
[annex]
    uuid = e9731ab7-6a76-4eef-b337-2b8573380014
    version = 6
[filter "annex"]
    smudge = git-annex smudge %f
    clean = git-annex smudge --clean %f

Thanks for the fix. Just to make sure I understand before breaking anything futher, the idea would be to move .git/annex/keys/db somewhere safe, git annex lock all the affected files, and then git annex fsck the whole repository? or just the affected files?

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.