Bug 8 - Directories in global font cache
Summary: Directories in global font cache
Status: CLOSED FIXED
Alias: None
Product: fontconfig
Classification: Unclassified
Component: fc-cache (show other bugs)
Version: 2.1
Hardware: x86 (IA32) All
: high normal
Assignee: Keith Packard
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-01-15 09:57 UTC by Owen Taylor
Modified: 2011-10-12 14:18 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Patch adding ".fulldir" (4.04 KB, patch)
2003-01-15 09:58 UTC, Owen Taylor
Details | Splinter Review
Marks cache entries "incomplete" with 0 timestamp (5.36 KB, patch)
2003-01-28 15:19 UTC, Keith Packard
Details | Splinter Review
Don't add directory to cache before scanning it (4.53 KB, patch)
2003-02-06 16:22 UTC, Keith Packard
Details | Splinter Review

Description Owen Taylor 2003-01-15 09:57:44 UTC
Say that you have no global cache file, and
a directory hierarchy:

 /usr/share/fonts
 /usr/share/fonts/ja

With some TrueType fonts in /usr/share/fonts/ja.

The fonts.cache-1 directories in /usr/share/fonts
and /usr/share/fonts/ja are both out of date.
(Or, there aren't any, I think the problem will
occur then as well.)

You run a program (like fc-list) that wants the
font configuration.

First, FcDirScan gets run on /usr/share/fonts,
when it hits /usr/share/fonts/ja FcFileScan
calls FcGlobalCacheUpdate(), which calls 
FcGlobalCacheDirAdd() and adds /usr/share/fonts/ja
to the dir.

When FcDirScan() then gets called on /usr/share/fonts
later on, it calls FcGlobalCacheScanDir(), which
sees the entry added by FcGlobalCacheDirAdd()
and says "OK, I know about that directory, it's
empty."

And the fonts in /usr/share/fonts/ja aren't found
at all.

Basic idea of fix:

 * The current .fonts.cache-1 file format does not allow 
   distinguishing the case of:

     Directory and contents in global cache 
     Just the directory in the global cache

   However, we need this distinction, since we can
   have both

   a/
    b/
     fonts.cache-1
     <stuff>

   And:

   a/
    b/
   
   And currently both cases will result in .dir entries
   for a/ and b/, but need to be treated differently.

Patch details:

 * The .fonts.cache file format is modified to do this
   by adding a ".fulldir" type to go along with the
   ".dir" type. ".fulldir" 

 * Two flags are added to the FcGlobalCacheDir structure:
   
    have_subentries - we have the entries for the
      contents of the directory, so we don't need
      to scan it again if we are up-to-date.
    scanned_subentries - we needed the entries for the
      contents of the directory, so we should write
      them back out.
 
   (The second field perhaps should be called 
   referenced_subentries, since it is similar to the referenced 
   field, but refers to the contents, not the directory
   itself.)

Notes:

 * The change here is compatible in one direction ... it
   will work with old ~/.fonts.cache-1 directory, however
   older versions of fontconfig will probably think
   that there are

   This probably means that it needs an update to 
   ~/.fonts.cache-2, however, I didn't want to make that
   name change in the Red Hat package without it being
   upstream as well.
Comment 1 Owen Taylor 2003-01-15 09:58:16 UTC
Created attachment 8 [details] [review]
Patch adding ".fulldir"
Comment 2 Owen Taylor 2003-01-23 17:47:04 UTC
Not to be too picky, but this isn't an enhancement, this is
a fix for a bug that makes fonts vanish from the system.
Comment 3 Keith Packard 2003-01-23 18:06:15 UTC
Oops, sorry for setting the priority wrong.
Comment 4 Keith Packard 2003-01-28 15:19:21 UTC
Created attachment 13 [details] [review]
Marks cache entries "incomplete" with 0 timestamp
Comment 5 Keith Packard 2003-01-28 15:21:24 UTC
The enclosed patch marks noticed-but-unscanned directories with 0 timestamp so
that they'll get scanned.  It also forces a directory scan anytime the global
cache has no entries for a particular directory.
Comment 6 Keith Packard 2003-02-06 16:20:50 UTC
No, the previous patch is quite wrong.  The actual bug was that the directory
was added to the cache when it was discovered, rather than when it was scanned.  Of
course, it was *also* added when scanned, so the fix is to delete the code that
added the directory to the global cache when discovered.  As the discovery adds
the directory to the list of directories, it will be scanned and added to the
cache at that point.  I'll attach a patch which simply deletes the extra cache
insertion (and includes a few other fixes).

Please see if this works.
Comment 7 Keith Packard 2003-02-06 16:22:02 UTC
Created attachment 17 [details] [review]
Don't add directory to cache before scanning it
Comment 8 Keith Packard 2003-02-12 12:33:52 UTC
After testing the proposed patch here, I've committed it to the tree.
Comment 9 Owen Taylor 2003-02-24 06:19:44 UTC
For reference ... note that the last patch on this bug had some
issues .... sometimes directories need to be in the cache even
when they aren't scanned, and a further fix went into CVS afterwards:

2003-02-13  keithp  <keithp@localhost.localdomain>

        * fccache.c, fcdir.c, fcint.h:
        Track dirs containing fonts.cache files referenced from ~/.fonts.cache file
Comment 10 Jeremy Huddleston Sequoia 2011-10-12 14:18:06 UTC
Closing old resolved bugs


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.