Comment 18 for bug 1749546

The problem as I understand it:

1. You have /usr/share/fonts/* on ext4 or similar FS with nanos.
2. /usr/share/fonts has a timestamp like 1522818676.601423551.
3. You run fontconfig and it stores the timestamp in the cache file.
4. You build a squashfs from the FS. Squashfs does not support nanos.
5. The timestamp of /usr/share/fonts inside the squashfs becomes 1522818676.0.
6. Installer boots and fontconfig sees the mismatched time stamps so rebuilds the cache in the live user's home directory - which is wiped at reboot.
7. During install the squashfs is copied back to an ext4 FS.
8. User reboots and logs in.
9. /usr/share/fonts is now on a filesystem which supports nanos, but the original time stamp nanos has been lost.
10. Fontconfig decides the cache is out of date and rebuilds it again, in the new user's home directory. This happens each time a newly created user logs in, until such time as a postinst script rebuilds the system font cache.

Note steps 9 and 10 only happen on Xubuntu and maybe some other flavours, but not Ubuntu.

This means that even if you could ask the system whether the filesystem supports nanos, that wouldn't be enough. It is possible for the timestamp information to be lost/mutated through squashfs, and then copied back to a filesystem with nanos, and then there is no way to determine whether that has happened or not.