just tried. but seems not help because generating cache in test case is finished too quickly. so checksum in FcCache and mtime is the same for all. then it considered no-updates. That looks like then watching the directory and update the cache on demand may be a solution for this issue though, is it too complicated? On Tue, Oct 1, 2013 at 4:49 AM, Behdad Esfahbod <behdad@xxxxxxxxxx> wrote: > On 13-09-29 11:54 PM, Akira TAGOH wrote: >> Hi, >> >> I think this may be a long standing issue and worked around with >> waiting for a few sec after updating the cache. but I've got a report >> and still reproducible and finally tracked it down and created 100% >> reproducible test case by having a logic to get rid of that >> conditional state. >> >> Let me explain how it happens first. fc-cache reads the directory to >> update the directory cache. as you may know this affects reading the >> sub-directories to find out fonts. >> If one is installing a new font while updating and finished reading >> the sub-directories on it. it won't updates the cache even if a >> directory is created/removed/renamed. and the cache is created without >> a directory where being installed a new font and won't be updated so >> that the cache's timestamp is newer than it. >> >> We may need to watch the changes on the directory while updating >> though, I just want to discuss the possible and the simple solution on >> this here. > > What about this: > > - When starting to create a new cache file, note the timestamp, > > - When the new cache file is written (right before renaming it to its final > name) set its timestamp to the timestamp noted above, > > - After writing the cache, retry from the start, check again whether the > cache needs updating. > > WDYT? > >> Thanks, >> >> https://bugs.freedesktop.org/show_bug.cgi?id=69845 >> > > -- > behdad > http://behdad.org/ -- Akira TAGOH _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
