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? > 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?) pat
