[Fontconfig] no `stable' cache file in `~/.fonts'

[Akira TAGOH]

In that version, we've tried to prevent the race on updating caches by
re-scanning a directory after updating a cache once. which isn't being done
on the latest anymore.

On Mon, Aug 29, 2016 at 5:07 AM, Werner LEMBERG <wl at gnu.org> wrote:

>
> [fontconfig 2.11.0]
>
> Running
>
>   fc-cache -v
>
> as a normal user, I see the following.
>
>     /usr/share/fonts: skipping, existing cache is valid: 0 fonts, 11 dirs
>     /usr/share/fonts/100dpi: skipping, existing cache is valid: 398 fonts,
> 0 dirs
>     ...
> ->  /home/wl/.fonts: skipping, existing cache is valid: 56 fonts, 1 dirs
>     /home/wl/.fonts/texlive: skipping, existing cache is valid: 0 fonts, 3
> dirs
>     /home/wl/.fonts/texlive/opentype: skipping, existing cache is valid:
> 0 fonts, 12 dirs
>     /home/wl/.fonts/texlive/opentype/adobe: skipping, existing cache is
> valid: 0 fonts, 3 dirs
>     /home/wl/.fonts/texlive/opentype/adobe/sourcecodepro: skipping,
> existing cache is valid: 14 fonts, 0 dirs
>     ...
> ->  /home/wl/.fonts: caching, new cache contents: 56 fonts, 1 dirs
>     ...
>     fc-cache: succeeded
>
> (I've added `fonts/{opentype,truetype,type1}' from a TeXLive
> installation as symlinks to `~/.fonts/texlive'.)
>
> What I don't understand are the two marked lines: Why does fontconfig
> first report a valid cache, then doing a caching operation inspite of
> this?
>
>
>     Werner
> _______________________________________________
> Fontconfig mailing list
> Fontconfig at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/fontconfig
>



-- 
Akira TAGOH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/fontconfig/attachments/20160829/b909ab98/attachment.html>