From: http://kerravonsen.dreamwidth.org/ Date: Fri, 26 Mar 2010 01:40:32 +0000 (+0000) Subject: oh dear not fixed after all X-Git-Url: https://sipb.mit.edu/gitweb.cgi/ikiwiki.git/commitdiff_plain/b68aa11732a1782886793e426f06652656c155cb oh dear not fixed after all --- diff --git a/doc/bugs/filecheck_failing_to_find_files.mdwn b/doc/bugs/filecheck_failing_to_find_files.mdwn index e896f2129..33975f05c 100644 --- a/doc/bugs/filecheck_failing_to_find_files.mdwn +++ b/doc/bugs/filecheck_failing_to_find_files.mdwn @@ -13,7 +13,13 @@ It turns out that the filecheck plugin couldn't find the file, because it was me >>> 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]] +>>> filecheck have the problem. --[[Joey]] + +>>>> Alas, not fixed. It seems I was mistaken in some of my assumptions. +>>>> It still happens when attempting to remove attachments. +>>>> With your fix, the `IkiWiki::srcfile` function is only called when the filename is not passed in, but it appears that in the case of removing attachments, the filename IS passed in, but it is the relative filename as mentioned above. Thus, the file is still not found, and the mime-type comes back as unknown. +>>>> The reason my patch worked is because, rather than checking whether a filename was passed in before applying IkiWiki::srcfile to the filename, it checks whether the file can be found, and if it cannot be found, then it applies IkiWiki::srcfile to the filename. +>>>> --[[KathrynAndersen]] The following patch fixes the problem: