Last modified: 2012-08-28 09:28:21 UTC
Initial state : MediaWiki 1.10.0 running fine on Windows IIS with : # PHP: 5.2.4 (isapi) # MySQL: 5.0.24a-community-nt After a successful update to 1.12.0, attempts to upload a file result in a 'filenotound' error: Internal error Unable to find file « C:\WINDOWS\Temp\php4AE.tmp ». php.ini's upload_tmp_dir is F:\Intranet\upload_tmp, not C:\Windows\Temp. The upgrade has not touched either of these directories, and MediaWiki was working 2 weeks ago with the previous version. Reverting to 1.10.0 (files only) makes the Upload feature usable as before, so I suspect the problem to be somewhere in SpecialUpload.php or in filerepo/
I finally tracked the bug down to PHP's is_file(), which in this case returns FALSE even though the file exists. The call is in includes/filerepo/FSRepo.php at line 286 (this is MW 1.12.0). I will edit the code to use some fopen() -based check instead of is_file() since it is very unreliable. I suspect that in this particular case, the folder permissions on C:\Windows\Temp (where the uploaded temp file is) do not allow is_open() to work correctly, while fopen() will. Perhaps some alternative form of checking would be good ?
More information as the investigation continues ... The problem is that upload_tmp_dir and Windows don't mix well : PHP will upload to C:\Windows\Temp whatever the upload_tmp_dir is. As a default on Windows Server, users do not have browse/read permissions on that directory. As a consequence, a bunch of PHP file-related functions WILL fail, including is_file() which is used in the new filerepo in MediaWiki 1.12.0 As such, the upload feature will be broken on every Windows Server Sytem where PHP (or the user) does NOT have read access to C:\Windows\Temp, that is, almost everyone but the admins on a default install. Suggestions : - revert to move_uploaded_file(), which did return FALSE in case of an error, making is_file() redundant ; - use some test not based on is_file() (@fopen() would do)
Note on the test. If you do switch to some other test. For the sake of clean code please implement that inside of a wfIsFile function inside of GlobalFunctions.php and use that.
Will do. Do you imply that I should paste a patch here too ? I do not have GNU diff nor SVN access here, where the Wiki is installed :-/
Just a quick comment to let you know that the bug still exists in 1.13.2 I will upload a patch soon.
Created attachment 5570 [details] Proposed patch to correct is_file problem on Windows platform Created a wfIsFile() function and replaced filerepo calls to is_file() with calls to that new function. Works for me using MW 1.13.2 on Win2K3 Server
For the record, other functions that fail on Windows when the parent directory is not user-readable include stat() and filesize(). As a result, uploaded files will all have a size of 0kb in the circumstances described in this bug. I believe we're left with 3 options : * file a bug against PHP. I suspect that it is a bug indeed, but I don't expect much here ... at any rate, it would probably take ages. So far I haven't found any similar report yet ; * write a wfFilesize() function based on fopen() and fstat() and replace calls to filesize() with it. Not a very pretty hack, but works for sure ; * have our respective admins move PHP's upload_tmp_dir, hence circumventing the problem.
I have attempted this patch on 1.15.1 on an IIS server, and it appears to help. I have to refresh sometimes to get it to go through, but it does work. The refreshing part is strange. I don't know why it would only work sporadically, but at least it solves the problem to a point.
Did some poking in the PHP bugs list, came across http://bugs.php.net/bug.php?id=39451, adding +upstream It was reported fixed in 5.2.1, but that seems to conflict with our bug report here. Similar bugs are closed Bogus/No Feedback/etc.
Somehow I had missed that one, thanks for the heads-up. But as you mentioned, it does not appear to be *really* fixed, at least not on our system running 5.2.4, so that's pretty weird. I'll try and set up a test server where I can experiment with this, and then I'll get back to you. Also, for the record : http://bugs.php.net/bug.php?id=46378 http://bugs.php.net/bug.php?id=44420
The bug is indeed caused by Windows' "special" way of handling file and folder permissions. Having correct user rights on the upload_tmp_dir is not enough, users also need READ/LIST permissions on the PARENT dir as well (see PHP bug 46378 in my previous comment).
Have there been any updates to this bug? It seems like the error is still cropping up for different people. I've attempted the recommended fix, but it looks like it's for an older version of MediaWiki. I've also tried replacing all instances of is_file with wfIsFile but I continue getting the same "C:\Windows\Temp" error. When I tried replacing all instance of file_exists with wfIsFile, the website won't load anymore, which wasn't too surprising, but I thought was worth a shot. Any help would be appreciated.
I don't run the Windows-based Wiki anymore, so I don't have any news on this topic. Also, I managed to get the admin to point the temp upload folder to a place where folder permissions wouldn't get in the way ; this is IMHO the best solution so far. The wfIsFile() hack worked back then, I see no reason why it shouldn't any more, but I can't reproduce this setup now, so I'm afraid you're on your own.
If this bug's affecting anyone, please try out the 1.18 beta per http://lists.wikimedia.org/pipermail/mediawiki-announce/2011-November/000102.html and see whether the bug's still reproducible, and report back. Thanks!
I am closing this bug report since it is most definitely related to very tricky Windows file permissions. There is really nothing we can do about it.
