mr-smoke wrote:

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 ?

mr-smoke wrote:

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.

mr-smoke wrote:

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 :-/

mr-smoke wrote:

Just a quick comment to let you know that the bug still exists in 1.13.2

I will upload a patch soon.

mr-smoke wrote:

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

attachment is_file-windows.patch ignored as obsolete

mr-smoke wrote:

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.

mlarson wrote:

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.

mr-smoke wrote:

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

mr-smoke wrote:

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).

miguelag wrote:

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.

mr-smoke wrote:

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.

sumanah wrote:

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.