1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
|
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.
|