Re: [PATCH] Do not remove UUID file when a scanned directory is empty

Akira TAGOH <[email protected]> Tue, 30 Oct 2018 13:16:48 +0900
Newsgroups gmane.comp.fonts.fontconfig
Message-ID <CACT-Cx1yG3t8WDNE_ODr27TaZiMQGCD+UqNd4iAhg=GpGVVqPQ@mail.gmail.com>
On Tue, Oct 30, 2018 at 7:05 AM Keith Packard <[email protected]> wrote:
> Hrm. I didn't understand what the uuid files were being used for.

That is to identify font directories and cache files identifically
even if those are *bind-mounted*.

> Reading through the code, it looks like they are an attempt to share
> cache files when there is more than one path name used for the same
> directory? And that by storing the UUID file in the font directory, you
> provide a stable name for the cache file even if the directory is
> accessed through a different path name.

Correct.

> If this is true, then I'm not sure I can see how we could move the .uuid
> files to a separate directory and retain this property.

Yes. there was some idea to implement this but it was simplest way to do.

> Is my understanding of why this mechanism was created correct? If so,
> I'd like to suggest that we just remove it; I think it's more important
> for fontconfig to avoid modifying the font directories than for it to
> avoid replicating cache information in the (rare?) case that there is
> more the one path to the same font directory.

Not rare today. this has been made to improve flatpaks startup time
because regenerating fontconfig caches always happened.

> We could use the 'realpath(3)' function during the generation of the
> cache file name; that would at least avoid having symlinks cause
> problems.

That won't help in this case. this isn't introduced by symlinks at all.

>
> --
> -keith



-- 
Akira TAGOH
_______________________________________________
Fontconfig mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/fontconfig