Bug 140335 - Installing fonts packages in fast machine will not update the /usr/share/fonts/fonts.cache-1
Installing fonts packages in fast machine will not update the /usr/share/font...
Status: CLOSED RAWHIDE
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: fontconfig (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Owen Taylor
:
Depends On:
Blocks: 137149
  Show dependency treegraph
 
Reported: 2004-11-22 08:40 EST by Leon Ho
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version: fontconfig-2.2.3-7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-12-05 22:22:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
proposed patch (1.07 KB, patch)
2004-11-22 13:16 EST, Akira TAGOH
no flags Details | Diff
proposed patch (1.06 KB, patch)
2004-11-22 13:20 EST, Akira TAGOH
no flags Details | Diff

  None (edit)
Description Leon Ho 2004-11-22 08:40:01 EST
Description of problem:
When installing fonts packages in fast machine, even though the %post
has fc-cache /usr/share/fonts, it will not update the
/usr/share/fonts/fonts.cache-1 properly with new directories and files.

How reproducible:
everytime

Steps to Reproduce:
1. Get ttfonts-indic-1.7-2
2. rpm -e ttfonts-bn ttfonts-gu ttfonts-hi ttfonts-ta ttfonts-pa
3. rpm -Uvh ttfonts-*-1.7-2*.rpm
4. cat /usr/share/fonts/fonts.cache-1
  
Actual results:
Not all new directories is in /usr/share/fonts/fonts.cache-1

Expected results:
All new directories is in /usr/share/fonts/fonts.cache-1

Additional info:
Comment 1 Akira TAGOH 2004-11-22 09:25:48 EST
I consider some solution for this:
1. on fontconfig side, though this may be not the best solution,
comparing the actual total numbers of directories and nsubdirs() would
improves to recognize the changes.

2. if you think it's not a bug, ttfonts-* package maintainer could
just do touch -t `date -d '1 second ago' +%Y%m%d%H%M.%S`
/usr/share/fonts/fonts.cache-1 and touch -t `date +%Y%m%d%H%M.%S`
/usr/share/fonts to avoid this. but I doubt it's the right fix.
Comment 2 Owen Taylor 2004-11-22 11:27:33 EST
Not an immediate solution, but one possibility would be to 
add an option to fc-cache that is like '-f' but only for
the toplevel.

So,

 fc-cache --force-one-level /usr/share/fonts

would force scanning of /usr/share/fonts, but trust modtime
for subdirectories.
Comment 3 Akira TAGOH 2004-11-22 13:16:42 EST
Created attachment 107211 [details]
proposed patch

Owen, how about this patch? this problem is caused by not updating the parent
fonts.cache-1 at least. even if the modification time is the same between the
directory and the file, fc-cache with this patch can detects the new sub
directory and assumes that fonts.cache-1 is invalid.
Comment 4 Akira TAGOH 2004-11-22 13:20:13 EST
Created attachment 107212 [details]
proposed patch

Oops, this is correct one.
Comment 5 Leon Ho 2004-11-23 01:17:38 EST
Owen, what is your suggestion here? We might randomly hit this bug
depends on how fast do users install.

Should we patch fontconfig, or to modify all of the ttfonts-* packages?
Comment 6 Owen Taylor 2004-11-24 16:38:40 EST
The problem with the patch above is that it only handles the
problem for a single level, which works for this particular
case, because we have direct subdirs of but leaves many similar
problems elsewhere.

What I discussed with Keith was making fc-cache call FcDirScan
with a special mode where it would ignore timestamps for directories
and trust them only for files.

You wouldn't want to do that for all uses of FcDirScan (too
expensive to do a full tree walk of the filesystem every time
an app starts), but doing it for fc-cache is likely OK.
Comment 7 Akira TAGOH 2004-11-25 01:59:49 EST
Ok, I see. so %post on each ttfonts-* packages needs to be changed
after that, right?
Comment 8 Owen Taylor 2004-11-25 09:51:06 EST
I think the mode can be the default for 'fc-cache'; I don't
think that will be too slow. So no changes to the %post will
be necessary.
Comment 9 Owen Taylor 2004-12-01 15:30:43 EST
Turned out to be harder to do that fix then I thought.

What I ended up doing was a very simple suggestion from
Keith Packard ... put a sleep(1) right before the termination
of fc-cache. This will make the install 15 or seconds slower,
which is definitely unfortunate, but is a very low risk
change, which is good at this point.

fontconfig-2.2.3-6 has that fix (tested with some artificial
cases.) Further tesing appreciated.
Comment 10 Leon Ho 2004-12-02 23:16:01 EST
It works quite okay, and the speed is not bad when install those 5
packages. Now installing between packages there are slight delay (no
HDD activities). 

Waiting for i18n QA to verify this as well before closing.
Comment 11 Lawrence Lim 2004-12-05 22:22:00 EST
Confirm fixed. Tested with fontconfig-2.2.3-7 and ttfonts-indic-1.8.1
on an average machine and a fast machine, the entries are now updated
properly.

Thanks.

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