srcfile_stat got called on a file from the underlay that no longer existed.
I am not 100% sure of the circumstances of that; I was able to reproduce
the bug but neglected to snapshot the tree, and then accidentially
got it to stop crashing. I know that a transient tag page got deleted using
the web interface to trigger the crash.
It seems that process_changed_files must have returned the file, despite it
being deleted. And since the file was not checked into git, it seems it
must have not been included in @IkiWiki::underlayfiles, which would have
caused process_changed_files to not return it.
I do not know why a transient tag page would not be in
@IkiWiki::underlayfiles. There is a bug here that I don't understand.
This is just a workaround -- run srcfile_stat such that it won't crash,
and if it is unable to stat a file, find_changed knows it's not changed,
so it's ok to skip it.
Also made find_new_files run srcfile_stat such that it won't crash, just
because I was there.
- suggest ghostscript (required for PDF-to-PNG thumbnailing)
and libmagickcore-extra (required for SVG-to-PNG thumbnailing)
- build-depend on ghostscript so the test for scalable images can be run
I have benchmarked the pagename() call this avoids taking up to 2 seconds
for a loadindex in a large wiki. The total loadindex for that wiki was
6.46s, so this is a significant improvment.
Even on a smaller site, this reduces the refresh time from 1.69 to 1.52
seconds.
The only breakage risk here is that pagename() can change the page name
it calculates due to setup changes. But in the case of a setup change, the
whole site is rebuilt. So the cached page name is not used in that
case.
I *think* this is ok, at least it results in close to the same index being
saved as before. The difference is that plugins that have a pagestate of {}
have that recorded this way, while with the tight loop, the key for the
plugin in not copied in that case. I cannot see how this could matter.
Simon McVittie
Joey Hess