Last modified: 2010-05-15 15:38:46 UTC
Note Mediawiki is installed on a OpenBSD server running php 5.0.5.
I know this has been reported previously, and is a dealt with as a FAQ on the install
site, however I think there is a genuine bug with the uploading of files which manifests
itself as the message:
"The file you have uploaded seems to be empty. This might be due to a typo in the
filename. Please check whether you really want to upload this file".
I have checked all the obvious problems such as permissions on the images directory +
apache and php settings. Moreover other php based software residing on the same server
is allowing the uploading of large files without any issues.
I'm not a php expert but have delved a little bit into the code of includes/
SpecialUploads.php. Indeed the upload size of the file does seems to be zero when the
following expression is evaluated:
if( trim( $this->mOname ) == '' || empty( $this->mUploadSize ) )
although the name filename is correct (and is not empty, but does not contain the full
path). If I manually set the value of mUploadSize to a value > 0 then I induce a further
issue to do with invalid file extensions, if I comment out the code for checking valid
extension, then I start to get messages which suggest that details of the file are not
correctly being passed to the module (hence it evaluating the file size to 0):
Warning: fread(): supplied argument is not a valid stream resource in /usr/local/apache/
htdocs/knowledgebase/includes/SpecialUpload.php on line 746
Warning: fclose(): supplied argument is not a valid stream resource in /usr/local/apache/
htdocs/knowledgebase/includes/SpecialUpload.php on line 747
Could not copy file "" to "/usr/local/apache/htdocs/knowledgebase/images/temp/f/f8/
I have tried using IE/Firefox and Opera with the same result.
1) Is the file you're uploading larger than the maximum upload size in php.ini?
2) Is the file you're uploading larger than the maximum post size in php.ini?
3) Are broken "security" features in PHP such as "safe mode" or "open_basedir" on in
4) Is this a genuine PHP or some hacked-up OpenBSD version which is more "secure" by
breaking uploads? ;)
As I said in my original message I have checked the php.ini to make sure it allows
the size of files I am wanting to upload. In any case, I am able to upload exactly
the same files using other php based applications running on the same server. There
are no extra security features in my PHP install, and it was compiled from source
without any OpenBSD specific features. Again I say that I can upload exactly the
same files using other php based applications running on the same server.
I have no experience of PHP, but am willing to try and hack the scripts if this will
help point towards the cause of this problem. However I need advise on what I need
to be looking at and checking.
I also notice strange behaviours:
a) the file size being 2,7 MByte, but the wiki upload function says"...file size
is 571 344 bytes" and
b) the "Could not copy file
Uploads of 700.000 byte big files w/o problems.
While we get to the bottom of this problem, is there a way of manually uploading
files using ftp such that mediawiki will recognise the files? I have tried placing
image files in the /images directory but mediawiki doesn't seem to recognise these
when I place the image tag in the text.
MediaWiki maintains information about image uploads in a database. Furthermore,
the images directory is, by default, structured in a "hashed" manner, with
folders named, for instance:
...and so forth. The software doesn't like recognising files in other locations.
Having said that, one could upload the images elsewhere, and configure MediaWiki
to use that location as a shared upload directory; see
for information on this feature, and how to configure it.
Rob thanks for your help.
Please close this bug, I began to experience other problems
with php not being being able to write its session data to
files. I subsequently downgraded php from a 5 to a 4
stream and everything seems to have begun working again
including the uploading of files using wikimedia.
Many thanks everyone for your speedy responses.