On Tue, 2005-09-27 at 18:12 +0200, Lubos Lunak wrote: > On Tuesday 27 September 2005 17:47, Patrick Lam wrote: > > Lubos Lunak wrote: > > > However, when I tested the 2.3.90 release yesterday, I was originally > > > disappointed to see it performed noticeably worse than the last stable > > > version. Short version: Please apply the attached patch. Longer version: > > > The problem turned out to be directories that contain files that > > > fontconfig doesn't seem to use yet it analyses them (.pcf.gz files). If a > > > directory contains only .pcf.gz files and has no subdirectories, then the > > > code that the patch removes will not write a cache file, yet the return > > > FcTrue means the directory has been successfully cached. However if you > > > look in > > > FcCacheReadDirs() you can see that if it can't use the cache file it will > > > call FcDirScanConfig(). So I suggest the attached patch which will write > > > a more or less empty cache file even in such directories. > > > > I'm not sure that this patch will not cause problems. I think that I > > want to generate a zero-length file in such a case, without a header at > > all. But I'm a bit confused: when I run fc-cache in a directory with > > only pcf.gz files, fc-cache *does* generate a fonts.cache-2 file for me. > > Why is this different for you? > > Maybe that directory you have has also a subdirectory? In the attached file > there's output of 'ls' in /usr/X11R6/lib/X11/fonts/latin2/misc and also the > output of 'fc-cache -f -v'. You can see that it says 0 fonts, 0 dirs, which > AFAICS exactly matches the condition my patches removes. > > > > > > And, actually, it seems I've just found another problem :(. If I run > > > Konqueror, run 'fc-cache -f' and go back to Konqueror, it crashes quite > > > soon. Guessing from strace of fc-cache, where I cannot see any call to > > > unlink(), and from the calls to ftruncate() I assume that the new cache > > > file contents are written directly in the same file instead of unlinking > > > the old file first, and fontconfig doesn't survive that. As I don't > > > understand the code that much I cannot confirm this theory for sure, > > > which also means no patch for this, sorry :). > > > > Which cache file are you talking about? $HOME/.fonts.cache-2, or a > > directory cache? (Are you running fc-cache as root?) > > Any cache file I'd say (and yes, I ran fc-cache as root). AFAIK if you > truncate a file that's mmap-ed, any access to the no longer existing part of > the file results in bad things. I don't know the structure of the cache file, > it seems to me it can be built in several steps for different architectures, > but I'd expect that the code can't cope with the data simply changing under > its hands, and unless the format specifically prevents that I'd expect that > to happen. Would there be any problem if you simply unlinked the old file > before writing the new one? > Thats what we do with other mmapped caches in GTK+, atomically replace them by writing the new cache to a tmp file, and then moving it in place. Matthias
