[Fontconfig] Patch: fix for fc-cache with relative path

[Frederic Crozat]

Le lundi 09 janvier 2006 à 21:06 +0700, Patrick Lam a écrit :
> Frederic Crozat wrote:
> > Hi,
> > 
> > the new cache location code has introduced new bugs in fontconfig :
> > -when using fc-cache . in a directory, the string used to generate
> > md5sum key is always "./fonts.cache-2" which will collide if the same
> > command is run in several directories.
> > -a similar problem happen when using : fc-cache /foo/bar and
> > fc-cache /foo/bar/ : strings used to generate md5sum are not the same,
> > resulting in different cache.
> > 
> > The attached patch fixes the issue.
> 
> I've committed my patch.

Good, I'll test it later this week. I knew about realpath ugliness but I
couldn't figure a good way to replace it (too bad fontconfig doesn't use
glib ;)


> > -in some directories containing only ttf fonts, running fc-cache -v
> > again and again always regenerate the cache (which is strange, since the
> > directory was not modified at all).
> > -this last bug is causing huge delays when starting applications for the
> > first time after running fc-cache as root, since cache is detected as
> > dirty and fontconfig regenerates it for the user (and on my test system,
> > I have two big chinese fonts of 20MB  and 16MB ...).
> 
> Do you have any more hints on when these problems occur?

Those two patches are no longer reproducible after removing all files
in /var/cache/fontconfig and re-running fc-cache with my "realpath"
patch. I guess old broken cache where causing this. People which were
reporting similar issues on cooker confirmed it fixed it.

I guess your similar fix will have a similar effect.

-- 
Frederic Crozat <fcrozat at mandriva.com>
Mandriva