Last modified: 2012-08-28 09:28:21 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 14213 - 1.12 (and up) upload fails on Windows Server
1.12 (and up) upload fails on Windows Server
Status: RESOLVED WORKSFORME
Product: MediaWiki
Classification: Unclassified
Uploading (Other open bugs)
1.13.x
PC Windows Server 2003
: Normal major with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
: testme, upstream
Depends on:
Blocks: iis
  Show dependency treegraph
 
Reported: 2008-05-21 18:17 UTC by Romain Riviere
Modified: 2012-08-28 09:28 UTC (History)
7 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Proposed patch to correct is_file problem on Windows platform (2.96 KB, patch)
2008-12-09 19:56 UTC, Romain Riviere
Details

Description Romain Riviere 2008-05-21 18:17:45 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/
Comment 1 Romain Riviere 2008-05-27 08:21:24 UTC
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 ?
Comment 2 Romain Riviere 2008-05-27 12:03:40 UTC
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)
Comment 3 Daniel Friesen 2008-05-27 16:42:23 UTC
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.
Comment 4 Romain Riviere 2008-05-28 13:23:08 UTC
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 :-/
Comment 5 Romain Riviere 2008-12-09 19:28:40 UTC
Just a quick comment to let you know that the bug still exists in 1.13.2

I will upload a patch soon.
Comment 6 Romain Riviere 2008-12-09 19:56:34 UTC
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
Comment 7 Romain Riviere 2008-12-29 13:34:00 UTC
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.

Comment 8 Mark Larson 2009-07-29 22:32:24 UTC
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.
Comment 9 Chad H. 2009-10-22 14:08:04 UTC
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.
Comment 10 Romain Riviere 2009-10-22 17:38:21 UTC
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
Comment 11 Romain Riviere 2010-09-24 07:00:01 UTC
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).
Comment 12 miguelag 2011-04-19 18:07:07 UTC
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.
Comment 13 Romain Riviere 2011-04-22 17:35:35 UTC
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.
Comment 14 Sumana Harihareswara 2011-11-09 04:23:33 UTC
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!
Comment 15 Antoine "hashar" Musso (WMF) 2012-08-28 09:28:21 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links