The code reading the fncache changed in 5.0, to complain if the file
is not \n terminated. This makes apparent the fact that the fncache
Make it possible to recover, instead of having `hg
debugrebuildfncache` failing by saying (run hg debugrebuildfncache).
The corruption itself is most likely due to hg not using fsync in
general, and so various bad things can happen. Here, the reported
problems happened when running out of disk space. So I suspect that
because the fncache is much bigger than the average commit/pull, when
running out of disk space, the bulk of the pull may succeed, but the
new fncache may get half-written and still renamed into place.