Bug 9 - Support fontconfig caches in /var
Summary: Support fontconfig caches in /var
Alias: None
Product: fontconfig
Classification: Unclassified
Component: library (show other bugs)
Version: 2.1
Hardware: x86 (IA32) Linux (All)
: high enhancement
Assignee: Keith Packard
QA Contact:
Depends on:
Blocks: DEMO_1
  Show dependency treegraph
Reported: 2003-01-16 08:49 UTC by Owen Taylor
Modified: 2014-11-19 06:09 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Description Owen Taylor 2003-01-16 08:49:39 UTC
It would be nice if /usr is readonly, fontconfig could create
cache files in a different location, maybe in a parallel
heirarchy under /var.

This relates to:

Comment 1 Keith Packard 2003-02-06 16:32:19 UTC
if /usr is read-only, is there a compelling reason why it couldn't include
pre-built cache files?  The cache system is designed to handle that gracefully.
Comment 2 Owen Taylor 2003-02-10 20:17:47 UTC
If you look at the upstream bug report, you'll see that the
original problem being reported there is that fontconfig
does _not_ handle the situation gracefully. 

The fontconfig package does a fc-cache -f on install and
if that can't write a cache file, it exits with a non-zero
error code.
Comment 3 Bugzilla Administrator 2003-02-10 22:00:55 UTC
I guess one option would be to have fc-cache not consider failure to write the
cache files as an error condition.  It's not fatal as fontconfig handles this
condition by creating per-user cache files as needed.  Would that suffice?  Or
would you really rather risk cache inconsistencies that could easily happen were
the cache file separated from the font directories?  In this case, if the cache
files really are up-to-date, then fontconfig will happily them.  Now that the
cache files are versioned, the risks of incorrect cache data from an older
version on the server causing problems have been substantially reduced.
Comment 4 Owen Taylor 2003-02-11 10:02:49 UTC
Well, the main reason that I suggested the /var approach was that
I recalled you being in favor of it at one point.

I think the approach of quietly not writing cache files in
read-only directories is probably fine. (If it isn't an 
error, nothing should be printed out unless you provide
some sort of 'verbose' command line flag.)
Comment 5 Keith Packard 2003-02-11 10:13:15 UTC
Having separate cache files holds a certain appeal, but I fear a certain amount
of chaos if system clocks aren't tightly synchronized or if file systems get
moved around.  I'd rather go with the "safe" approach that we currently support,
or (alternatively) build yet another level into the cache system that could
provide a system-wide "global" cache file, much like ~/.fonts.cache-1.  That
seems like a lot of work, especially as we consider it likely that people will
be able to pre-build fonts.cache-1 files on the read-only media (or manage them
from the central server).

It appears that access(2) will correctly detect EROFS errors; perhaps fc-cache
should just skip directories for which it has no write permission.  That seems
more sensible than building the cache and then not generating an error when
writing that fails.
Comment 6 Keith Packard 2003-02-12 12:36:26 UTC
I've committed a patch to fc-cache that skips unwritable directories.  This has
the salutory effect of skipping all of the system-wide font directories when the
user runs fc-cache, while also avoiding problems with read-only file systems.

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.