When fc-cache runs, it creates .NEW and .LCK files. If fc-cache is killed before it can delete/rename these files, then they persist. Rerunning fc-cache will then fail to update the cache until these files are manually deleted. I would expect that the "-r" switch ("erase all existing caches") would delete these files as well (or at least overwrite them).
What platforms did you see any issue? .NEW file itself is always removed at first when trying to lock. so even if it keeps staying that should be no problem. so I guess you mean it is when .LCK is kept there. in that case fontconfig will check the time and try to remove it if it was created more than 10 mins ago when fontconfig considered locking is getting stuck. you better trying 10 mins later rather than removing them forcibly anyway. if it doesn't even work, please let me know.
I'm sorry, I forgot to post a usable bug report. fontconfig version: 2.12.1 System: Windows 7, 64 bit, using a roaming user profile (though I doubt this makes any difference). I am using fontcache through GNU Octave and the Qt graphics toolkit. This is related to an Octave problem (https://savannah.gnu.org/bugs/?45458). The original problem in Octave is that after program start, the first plot command takes unusually long to complete (tens of seconds up to minutes). I (and others) have traced this to fc-cache recreating the fontcache every time Octave is restarted. Unfortunately, I can not reliably reproduce the bug anymore since *something* fixed it while running fc-cache as Administrator and using "-r", and now it does not occur anymore. I cannot rule out that this may have been a problem with write permission. I tried to verify the "delete after ten minutes" functionality, but it does not seem to work on windows. I created a .LCK file by appending .LCK to the cache file in the directory. The file persists even if it is days old, and was not deleted by fc-cache (nor "fc-cache -r"). This might be a windows-only problem.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/19.
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.