| Summary: | FcAtomicLock fails on OS X on network mounts | ||
|---|---|---|---|
| Product: | fontconfig | Reporter: | michael-lists |
| Component: | library | Assignee: | fontconfig-bugs |
| Status: | RESOLVED FIXED | QA Contact: | Behdad Esfahbod <freedesktop> |
| Severity: | normal | ||
| Priority: | medium | CC: | akira |
| Version: | 2.11 | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Mac OS X (All) | ||
| See Also: |
https://bugs.freedesktop.org/show_bug.cgi?id=30077 https://bugs.freedesktop.org/show_bug.cgi?id=95477 |
||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
fixed in git. |
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.
On OS X systems (in my case, OS X 10.9.4), if the cache folder is on a mounted network share (e.g. because the user's home directory is on an SMB or AFP server), running fc-cache will fail to write to ~/.cache/fontconfig. This means the lengthy caching process is performed every time fontconfig is used. The issue can be fixed by applying the patch below as evidently, OS X returns ENOTSUP when link() is performed on a file system that does not support hardlinks instead of EPERM. The issue occurs in fontconfig 2.10 and 2.11, possibly older ones as well. --- src/fcatomic.c.orig 2012-05-28 15:58:56.000000000 +0900 +++ src/fcatomic.c 2014-08-07 11:47:45.000000000 +0200 @@ -131,7 +131,7 @@ FcAtomicLock (FcAtomic *atomic) return FcFalse; } ret = link ((char *) atomic->tmp, (char *) atomic->lck); - if (ret < 0 && errno == EPERM) + if (ret < 0 && (errno == EPERM || errno == ENOTSUP)) { /* the filesystem where atomic->lck points to may not supports * the hard link. so better try to fallback