Created attachment 128889 [details] 0001-Fix-cache-file-update-on-MinGW-and-Cygwin.patch If you have an old cache file and need updating, the updating fails on Windows (both MinGW and Cygwin). On Windows, opened or locked files cannot be removed. Since fontconfig locked an old cache file while updating the file, fontconfig failed to replace the file with updated file on Windows. I've created a patch. It makes fontconfig does not lock the old cache file while updating it on Windows (both MinGW and Cygwin).
Created attachment 128946 [details] [review] v2-0001-Bug-99360-Fix-cache-file-update-on-MinGW.patch Cygwin snapshot has been fixed its API. So this issue is no longer reproduced on Cygwin snapshot. https://cygwin.com/ml/cygwin/2017-01/msg00132.html https://cygwin.com/ml/cygwin/2017-01/msg00163.html However, on MinGW, fontconfig still has the issue. I've updated my patch.
Would you merge my patch? This issue is very major and serious to use fontconfig on Windows. Certainly, my patch is not perfect. However, the current fontconfig always fails to update the cache. With my patch, fontconfig almost succeeds to update the cache. It obviously improves the issue, in my humble opinion. W32TeX (a TeX binary distribution for Windows) has applied my patch. http://w32tex.org/ChangeLog has the following description. ...snip... [2017/01/15] ...snip... (02) xetex-w32.tar.xz Apply a patch for fontconfig by M. Hosoda: https://bugs.freedesktop.org/show_bug.cgi?id=99360. Now XeTeX can update font cache files. ...snip... (04) win64/xetex-w64.tar.xz Apply a patch for fontconfig by M. Hosoda: https://bugs.freedesktop.org/show_bug.cgi?id=99360. Now XeTeX can update font cache files. ...snip... In W32TeX, the issue has been resolved, and problems caused by the patch have not raised.
Cygwin 2.7.0 has been released and its API has been fixed. This issue is no longer reproduced in the released version of Cygwin. https://cygwin.com/ml/cygwin/2017-02/msg00161.html https://cygwin.com/ml/cygwin/2017-01/msg00108.html However, on MinGW, fontconfig still has the issue. My patch can solve the issue.
Fontconfig 2.12.3 (released today) still fails to rebuild the font cache on Windows (MinGW). LilyPond 2.19.56 for Windows (released Feb. 26, 2017) has applied my patch to the bundled fontconfig. https://github.com/gperciva/gub/commit/4092624f4fa85ae8c38fcb87646942f13583b26a Before applying the patch, the bug reports on font caching raised frequently. After releasing LilyPond 2.19.56, it has gone, except the case of using older LilyPond. There are no bug reports on the font cache for the last three months. Furthermore, TeX Live 2017 for Windows will be applied my patch. https://www.tug.org/svn/texlive?view=revision&revision=44334 This patch can solve font caching problems and it does not cause other problems.
Sorry, I missed that to take an action. the proposed patch has been merged into git.
(In reply to Masamichi Hosoda from comment #1) > Created attachment 128946 [details] [review] [review] > v2-0001-Bug-99360-Fix-cache-file-update-on-MinGW.patch Sorry, I found this bug only today, and when reading the patch I get the impression that the "fix" for bad locking is to remove any locking for Windows. So I wonder why locking was considered necessary. Also you cannot delete or rename a locked file in MS-DOS (Windows), so you'll have to unlock it before closing. (It seems in UNIX you lock a file descriptor, while in MS-DOS you lock a file name)
Speaking of the necessity of locking cache files on *nix, the caches can be updated from the multiple processes at the same time and they might have different state of caches depending on scanning font directories. thus, trying to lock before scanning and unlock after writing down a cache. why we take a fd, is that because the syscall of F_SETLKW requires it. I guess the issue around the file lock may be less likely to happen on Win32 because the caches may be not updated from multiple processes at the same time. though if you have any better idea to improve this, feel free to submit changes for that.
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.