I had an interesting one with a partner just now - their machine had died during / shortly after compilation (I suspect) with some graphics driver lockup and hard reset. On returning all was well for some days - but (it seems) now there were several zero length (but apparently valid) files in the ccache. Unfortunately, that meant on the next compile (of these un-changed files) - we got served up zero length .o files- which then failed to link (a zero length file is always a bad object file I think). So - it would be just lovely to either run fsync on each file as it goes into the cache [ this was on ext4 so -in-theory- that should do some good ], and/or check for and discard zero size .o files and refuse to hand them out / clean that cache entry & force re-compilation. Anyhow - many thanks for ccache - it saves libreoffice a ton of cycles normally ! :-)
Created attachment 9111 [details] fixed up prototype patch
(In reply to comment #0) > [...] > So - it would be just lovely to either run fsync on each file as it goes into > the cache [ this was on ext4 so -in-theory- that should do some good ], fsyncing each file would be way to slow, unfortunately. > and/or > check for and discard zero size .o files and refuse to hand them out / clean > that cache entry & force re-compilation. That sounds like a good idea, though!
(In reply to comment #1) > Created attachment 9111 [details] > fixed up prototype patch Thanks. I ported and applied your patch to the maint branch in 12e2badf739244dc97cad84a6fb1905ec3c4a76d (note "badf" in the hash - it's obviously a commit that fixes bad files...).
Thanks for the merge ! :-) I love the badf. FWIW - my experience of file-data corruption under the tender ministrations of non-fsynched ext4 file-systems is that you usually end up with perfect meta-data, and (usually zero) data. So - for the next round of improvement I guess that reading the first 16 bytes or so and checking they're not all zero's might also be a useful check [ and presumably with only a small perf. impact ]. I've not seen that happen yet though in the wild. Anyhow - thanks for ccache ... :-)
Fix included in v3.1.10.