### Please describe the problem.
We use git annex and found an issue where one machine that had run 'git annex sync' and 'git annex sync --content' was not reporting any issues, but any other machines were reporting 99 issues when running 'git annex get'.

The message for each file was that it was not known to exist on any repo. Doing some searching I found 'git annex fsck' so ran that in the following fashion on the 'broken' machines: 'git annex fsck --from=LocalMirrorName --fast'. During this we saw git was updating the location log for nearly all the missing files. Running 'git annex get' afterwards resolved the issue and got the files. We found we had to repeat this on all affected machines.

### What steps will reproduce the problem?
We've not been able to reproduce a brand new stance of the problem (and don't want to, rightly so). Some other machines still have this issue where we have not run the fsck.

### What version of git-annex are you using? On what operating system?
The machine that did the original sync was running git 2.7.4 on Ubuntu 16 and other
machines were either running the same, or 2.17.1 on Ubuntu 18.

### Please provide any additional information below.
A test I also tried: I copied one annex file from inside the .git folder of the original machine that ran the sync, and added it to the same location on a broken machine, then ran sync and get, and it reported 98 issues instead.

Does this seem like a bug with git annex? Is there a possible gap in the way that git annex reports that all is fine - perhaps to do with the index? Or does this seem to be more likely an issue we created ourselves? Would there have been any other commands we could have run to resolve this issue or should have tried out first? (Apart from just deleting each of our clones and starting again)

### 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)
Git annex works for us the majority of the time and solves a lot of space issues for us in a unique way. We do get confused by it sometimes, but that's probably our implementation of it and not knowing enough about it across our team (seems to be a set and forget approach).

> Closing as it's not clear this was a bug rather than user error as
> explained in my comment. [[done]] --[[Joey]]
