<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Dear Akira-san --<br>
<br>
<div class="moz-cite-prefix">Akira Kakuto wrote:<br>
</div>
<blockquote cite="mid:A4F1CA8FF173442EB1BFD956A5D07737@CJ3001517A"
type="cite">It seems that I was wrong:
<br>
<br>
By experiments, I found that the renaming,<br>
cachefile.NEW --> cachefile, almost always<br>
fails if executed from the XeTeX binary even<br>
in a user's writable directory. </blockquote>
Thank you -- further experiments after installing a further new font
have indeed shewn this to be the case. It would also seem that, in
my case at least, that I have write access to the default location
for FC_CACHEDIR so the effect of explicitly setting that to
C:\TeX\Live\2016\FC_cache was to allow the initial creation of a new
cache (which of course helped) but did not address the real problem
that you have identified with :<br>
<br>
#ifdef _WIN32
<br>
unlink ((const char *) atomic->file);
<br>
/* fails always if executed from the XeTeX binary */
<br>
#endif<br>
<blockquote cite="mid:A4F1CA8FF173442EB1BFD956A5D07737@CJ3001517A"
type="cite">Thus if you find a delay of time, run fc-cache -v.
<br>
<br>
If messages
<br>
invalid cache file: ...
<br>
are shown, run
<br>
<br>
fc-cache -v
<br>
<br>
once more.<br>
</blockquote>
Thank you, and noted for future reference.<br>
** Phil.<br>
<div class="moz-signature">-- <br>
<img src="cid:part1.09060800.07080609@Rhul.Ac.Uk"><br>
Philip Taylor</div>
</body>
</html>