On Fri, Jan 15, 2016 at 3:39 PM, Keith Packard <keithp@xxxxxxxxxx> wrote: > As long as the timestamp written to the cache is the directory change > time when the scanning starts, then applications starting after that > will re-scan the directory if it was changed while the first application > was scanning. I guess I don't see how this (which is what I think the > code does) could cause a race? Well, the scenario for the race is, installing a font A with a sub directory into the directory while fc-cache is collecting metadata from fonts at or traversing. so fc-cache writes out a dir cache without that subdir and no difference between mtime in cache and fs. then fontconfig can't reach out a cache file for A. > Alternatively, the library could re-stat the directory after building > the cache, and before replacing it in the file system, discarding and > rescanning the directory if the timestamp has changed. I tried that before. it happened with it behaved that way. because couldn't even detect the change from mtime so needed to check the difference of the number of entries in both cache and fs. -- Akira TAGOH _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
