InodeCache currently uses modificationTime which has a 1 second resolution.
(And when comparing weakly, further weakens to 2 second resolution.)

In [[!commit c28ca8294f7695c77e5f03762171e829de5d6ea4]], the clean filter
started checking the InodeCache to see if a file is modified.

This means that modifying a file, running `git add`, then modifying again
and `git add` within the same second won't stage the second version of the
file. (Although luckily it also compares file size.)

I think that optimisation needs to be disabled when inode caches will be
compared weakly, because 2 seconds is just too long. This will mean slow
`git checkout` on FAT and also when a user moves a repo to a different
filesystem. But I don't see a way to avoid it.

> Hmm, on second thought, that would mean every inAnnex on FAT
> would need to checksum the content. That's just too slow to be practical.
> `git annex fsck` will clean up if trusting the timestamps causes
> it to make a mistake on FAT.

Otherwise, the problem can be fixed by using modificationTimeHiRes.

But! All existing InodeCaches would then appear to have changed. This would
confuse handling of existing v6 repos badly. (And direct mode uses
InodeCache too..)

So, need to detect, when reading a serialized InodeCache,
if it's low res or high res. And when comparing two of different
resolutions, truncate to low res.

readInodeCache currently fails if the mtime contains a decimal, eg

	ghci> readInodeCache "1 2 3.1"
	Nothing

What would work, w/o breaking back-compat is

	ghci> readInodeCache "1 2 3 1"
	Just (InodeCache (InodeCachePrim 1 2 3))

So the decimal part of the mtime becomes the 4th word and old
versions of git-annex will ignore it.

> [[fixed|done]] --[[Joey]]