[Fontconfig-bugs] [Bug 103652] fontconfig requires nano second precison for fontcache

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=103652

--- Comment #6 from Alistair Buxton <a.j.buxton at gmail.com> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/fontconfig-bugs/attachments/20180404/6280c64c/attachment.html>