Re: [PATCH] Make the cache filenames determinstic

"Keith Packard" <[email protected]> Mon, 29 Oct 2018 23:00:29 -0700
Newsgroups	gmane.comp.fonts.fontconfig
Message-ID	<[email protected]>
Chris Lamb <[email protected]> writes:

> Dear Keith et al.,
>
>> I've dug into this a bit more and I think an architectural change in the
>> cache files made last year is probably not what we want.
>
> Thank you for providing this explanation. However, one thing that
> isn't clear to me is what the difference is between the (eg.) /var/
> cache/fontconfig/21328251-11eb-4cba-b230-50d60512f1c8-le64.cache-7
> files and the "/var/cache/fontconfig/.uuid" (or ".uuid") files?

Yes, it sounds like this is very unclear. The .uuid files are stored in
the font directories themselves and provide a stable name for the cache
file associated with that directory, even if the directory is accessed
through a different path. You won't find .uuid files in
/var/cache/fontconfig ever, you'll find them scattered all over
/usr/share/fonts.

From an RB perspective, using a reproducible mechanism to generate the
contents of the .uuid files (such as a hash of the path) would suffice.

From a system perspective, the .uuid files break one of the promises
that fontconfig makes to the user -- it isn't supposed to modify the
font directories. As fontconfig uses directory timestamps when deciding
whether to re-scan, anything which modifies those directories is prone
to changing timestamps, even if it's trying not to.

I discovered this whole mechanism when firefox started melting my CPU
with continuous font rescanning as any empty directory would get its
timestamp modified each time it was scanned...

> Sorry if this seems obvious from the outside; I am simply not well-
> versed in fontconfig lore.

The whole .uuid file thing was a surprise to me; I understand what it is
designed to solve and I'm hoping we can come up with a mechanism which
makes the font cache filenames reproducible *and* avoids modifying the
font directories on the fly.

If we need a special hack for Buster, we can simply remove the .uuid
file generation and go back to md5(pathname), which will solve the RB
problems but make things more expensive for anyone running flatpaks on
debian.

-- 
-keith

_______________________________________________
Fontconfig mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/fontconfig
signature.asc (application/pgp-signature, 832 B)