Bug 99360

Summary: Cache file update fails on Windows (also Cygwin)
Product: fontconfig Reporter: Masamichi Hosoda <trueroad>
Component: libraryAssignee: fontconfig-bugs
Status: RESOLVED FIXED QA Contact: Behdad Esfahbod <freedesktop>
Severity: major    
Priority: medium CC: akira, eduard.braun2, Ulrich.Windl
Version: 2.12   
Hardware: x86-64 (AMD64)   
OS: Windows (All)   
See Also: https://bugs.freedesktop.org/show_bug.cgi?id=101820
i915 platform: i915 features:
Attachments: 0001-Fix-cache-file-update-on-MinGW-and-Cygwin.patch

Description Masamichi Hosoda 2017-01-11 11:53:51 UTC
Created attachment 128889 [details]

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).
Comment 1 Masamichi Hosoda 2017-01-14 04:23:01 UTC
Created attachment 128946 [details] [review]

Cygwin snapshot has been fixed its API.
So this issue is no longer reproduced on Cygwin snapshot.

However, on MinGW, fontconfig still has the issue.
I've updated my patch.
Comment 2 Masamichi Hosoda 2017-01-31 14:57:27 UTC
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.

has the following description.

(02) xetex-w32.tar.xz
     Apply a patch for fontconfig by M. Hosoda:
     Now XeTeX can update font cache files.
(04) win64/xetex-w64.tar.xz
     Apply a patch for fontconfig by M. Hosoda:
     Now XeTeX can update font cache files.

In W32TeX, the issue has been resolved, and problems caused by the patch have not raised.
Comment 3 Masamichi Hosoda 2017-02-13 14:28:21 UTC
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.

However, on MinGW, fontconfig still has the issue.
My patch can solve the issue.
Comment 4 Masamichi Hosoda 2017-05-31 14:21:44 UTC
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.

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.

This patch can solve font caching problems and it does not cause other problems.
Comment 5 Akira TAGOH 2017-06-01 02:48:11 UTC
Sorry, I missed that to take an action. the proposed patch has been merged into git.
Comment 6 Ulrich Windl 2018-03-13 07:43:53 UTC
(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)
Comment 7 Akira TAGOH 2018-03-13 08:12:23 UTC
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.