Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 100589 - Stale /usr/share/fonts/fonts.cache-1 blocking fonts caching
Stale /usr/share/fonts/fonts.cache-1 blocking fonts caching
Product: Red Hat Linux Beta
Classification: Retired
Component: fontconfig (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Owen Taylor
Depends On:
Blocks: CambridgeTarget
  Show dependency treegraph
Reported: 2003-07-23 12:15 EDT by Michel Alexandre Salim
Modified: 2007-04-18 12:56 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-08-03 19:03:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michel Alexandre Salim 2003-07-23 12:15:23 EDT
Description of problem:
If new fonts are added under a new subdirectory under /usr/share/fonts (e.g.
installing bitstream-vera-fonts after Severn is installed), the fonts won't be
available even after running fc-cache unless fonts.cache-1 is removed first.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Create a new subdir, say 'test' under /usr/share/fonts/test
2. Copy a TTF file into said directory
3. Run 'fc-cache /usr/share/fonts'
Actual results:
cat'ing /usr/share/fonts/fonts.cache-1 does not list new 'test' directory - no
fonts.cache-1 created in 'test' either

Expected results:
/usr/share/fonts/fonts.cache-1 updated, fonts.cache-1 created in test as well,
new font available to fontconfig apps

Additional info:
/usr/share/fonts/fonts.cache-1 needs deletion before running fc-cache, then
everything works.
Comment 1 Owen Taylor 2003-07-23 12:55:21 EDT
Quick check - your system time is reasonable and was reasonable
during the install?
Comment 2 Michel Alexandre Salim 2003-07-23 13:03:33 EDT
Ah ! Err... guess that's it then. My clock is always NTP'ed, that's why I did
not suspect clock skew. I dual-boot with XP so I could not set system time to UTC.

Now to think of it, there *was* that warning that came up when starting sendmail
saying modification time is in the future.

But wait. My timezone is UTC+7, how did I manage to get future modification
time? Oh, timestamps are stored in UTC time...

Should I file a bug for Anaconda instead, an RFE asking for timezone selection
to be brought forward? A quick hack would be to set the system day back one day
before install, but that's.. ugh.
Comment 3 Owen Taylor 2003-07-23 14:29:12 EDT
Hmmm, the installer does have time zone selection, so if your
system clock is set to the right time (or approximately the
right time) then things should be fine.

Maybe you simply forgot to set the timezone during install?
If that was the case, then you'd get timestamps in the future
because I think the default is US/Eastern which is -0400, so
all your timestamps would be 11 hours in the future.
Comment 4 Michel Alexandre Salim 2003-07-24 00:07:18 EDT
I do not think I forgot the timezone twice in a row - in fact I am fairly
certain I selected it both times. What I reckon happened is that RPMs were
installed before timezone is selected, and say I do the install around 12pm UTC,
that is, 7pm Western Indonesia Time. The system thought my time was UTC because
I have not told it otherwise, so all files are stamped 7pm *UTC*. Then after
install is finished, Linux knows to subtract 7 hours from the reported hardware
time to get UTC time, so the filestamps are 7 hours in the future since in
reality it is still 12pm UTC.

Hope that made sense. Certainly explains why I get that sendmail warning quite
often after new installs - so, Anaconda bug?
Comment 5 Owen Taylor 2003-07-24 10:09:40 EDT
Cc'ing Jeremy Katz in case I'm wrong, but I believe the timezone setting
does take effect *before* the files are installed. There are many
reasons why you want timestamps right for package installation.

So, I think something else is going wrong with your install procedure;
perhaps your system clock is simply way off, and you haven't noticed
because you are using NTP?
Comment 6 Michel Alexandre Salim 2003-07-24 23:45:30 EDT
Rather unlikely; the software clock is saved to hardware when shutting down, and
since I did two installs one day after another, my clock has to be severely
dysfunctional to go off by a few hours in such a time span.

[michel@bushido michel]$ /usr/sbin/hwclock && date
Fri 25 Jul 2003 10:43:10 WIT  -0.968829 seconds
Fri Jul 25 10:43:09 WIT 2003

This is rather bizarre indeed...
Comment 7 Owen Taylor 2004-08-03 19:03:54 EDT
Closing as NOTABUG since I don't think there will be any more
useful information at this point.

Note You need to log in before you can comment on or make changes to this bug.