Using the attachment plugin, when filecheck was checking the mime-type of the attachment before allowing the attachment to be removed, it was returning with an error saying that the mime-type of the file was "unknown" (when the mime-type definitely was known!)

It turns out that the filecheck plugin couldn't find the file, because it was merely using the $pagesources hash, rather than finding the absolute path of the file in question.

> I don't understand why the file was not in `%pagesources`. Do you?
> --[[Joey]]

>> The file *was* in `%pagesources`, but what returns from that is the filename relative to the `srcdir` directory; for example, `foo/bar.gif`.
>> When File::MimeInfo::Magic::magic is given that, it can't find the file.
>> But if it is given `/path/to/srcdir/foo/bar.gif` instead, then it *can* find the file, and returns the mime-type correctly.
>> --[[KathrynAndersen]]

>>> Ok, so it's not removal specific, can in fact be triggered by using
>>> testpagespec (or really anything besides attachment, which passes
>>> the filename parameter). Nor is it limited to mimetype, all the tests in 
>>> filecheck have the problem. [[Fixed|done]] --[[Joey]] 

The following patch fixes the problem:

	diff --git a/IkiWiki/Plugin/filecheck.pm b/IkiWiki/Plugin/filecheck.pm
	index 01d4909..1cec0cf 100644
	--- a/IkiWiki/Plugin/filecheck.pm
	+++ b/IkiWiki/Plugin/filecheck.pm
	@@ -118,6 +118,10 @@ sub match_mimetype ($$;@) {
	 	if (! defined $file) {
	 		return IkiWiki::ErrorReason->new("no file specified");
	 	}
	+	if (! -e $file) {
	+	    # get the absolute path of the file if you can't find it
	+	    $file = IkiWiki::srcfile($file);
	+	}
	 
	 	# Use ::magic to get the mime type, the idea is to only trust
	 	# data obtained by examining the actual file contents.