Clone a repository containing an unlocked file, and `git annex get` it. The
object is transferred, but the pointer file does not get populated.
(`git annex fsck` will then notice and correct the problem.)

If any other git-annex command is run before the get, it avoids the
problem. So the problem has to do with autoinit followed by reading
associated files from the keys db.

Bisected to [[!commit 428c91606b434512d1986622e751c795edf4df44]] --[[Joey]] 

It seems that reconcileStaged is populating the
associated files, but later when they're queried, the query returns an
empty list. So something to do with database write caching.

Somehow, not having init call `scanAnnexedFiles` makes this bug go away.

> fixed --[[Joey]]

----

I have reopened this bug, it seems the previous fix was not right.
See [[!commit b3c4579c7907147a496bdf2c73b42238d8b239d6]] for that
fix, which had doubts at the time in the commit message. --[[Joey]] 

Here is a test case:

	git init foo
	cd foo
	git annex init
	echo 1 > foo
	echo 2 > bar
	echo 3 > baz
	git annex add
	git annex unlock
	git commit -m add
	cd ..
	git clone foo bar
	cd bar
	git-annex get
	cat *

This outputs 1 for foo, followed by annex pointer files for files bar and baz.

The previous fix attempt did make foo get populated, before that none
of the files were populated.

----

`GIT_TRACE=1` shows that git only runs the smudge filter on the first
file, not the other two. And indeed, restagePointerFile is only called
on the first file.

Added debugging to Database.Keys.reconcileStaged, and it adds all 3 files to
the associated files table, but only adds the inode cache of foo.
And that's what I see in the db after the fact too. Which is
not itself a problem, to the extent that the other files are not
populated, and only populated files have an inode cache recorded.

So, Database.Keys.reconcileStaged is called after it gets foo,
but before the other files are present, and in reconcilepointerfile it
calls populatePointerFile and records the inode cache for foo.
That is how foo gets populated.

But, the other 2 files do not have populatePointerFile run on them.
In moveAnnex, it calls getAssociatedFiles and somehow that returns
`[]`, for all 3 files. This does not matter for foo, because it gets
populated by reconcileStaged as explained above. But for the other 2, with
no known associated files of course it fails to populate them.

So: Why is getAssociatedFiles returning `[]`? Those calls come
after Database.Keys.reconcileStaged has added the associated files,
but are somehow not seeing the changes it made.

Ah.. The keys db is opened in MultiWriter mode. 
See the comment above the definition of MultiWriter,
which explains that a write to a MultiWriter database,
followed by a flushDbQueue may not be visible when reading
from that same database.

Verified this by making it re-open the db after reconcileStaged,
which did fix the problem.

A better fix is possible: Make MultiWriter mode not have this hidden
gotcha, by re-opening the db after writing to it always. [[done]]
--[[Joey]]
