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

In 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"

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 --Joey