When a FAT filesystem is unmounted and remounted, the inode numbers all
change. This makes import tree from a directory special remote on FAT
think the files have changed, and so it re-imports them. Since the content
is the unchanged, the unnecessary work that is done is limited to hashing
the file on the FAT filesystem. But that can be a lot of work when the tree
being imported has a lot of large files in it. 

This makes import tree potentially much slower than the legacy import
interface (although that interface also re-hashes when used with
--duplicate/--skip-duplicates).

Also, the content identifier log gets another entry, with a content
identifier with the new inode number. So over time this can bloat the log.

May be better to omit the inode number from the content
identifier for such a filesystem, instead relying on size and mtime?
Although that would risk missing swaps of files with the same size and
mtime, that seems like an unlikely thing, and in any case git-annex would
import the data, and only miss the renaming of the files. It would also
miss modifications that don't change size and preserve the mtime; such
modifications are theoretically possible, but unlikely.

But how to detect when it's a FAT filesystem with this problem?
The method git-annex uses when running on a FAT filesystem, of maintaining
an inode sentinal file and checking it to tell when inodes have changed
would need importing to write to the drive. That seems strange, and the
drive could even be read-only. May be the directory special remote should
just not use inode numbers at all?

> [[done]] --[[Joey]]
