Problem: File upload and IIS

ttunkka

What is wrong with file uploads in IIS?

PHP gives errors:
Warning: Unable to create '//WFIKLA005/files/303903ae520b201e0b.jpg': No such file or directory in files.inc.php on line 214

Warning: Unable to move 'c:\temp\phpA.tmp' to '//WFIKLA005/files/303903ae520b201e0b.jpg' in files.inc.php on line 214

Same scripts works in Apache fine, but not in IIS. I have checked all permissions for 'c:\temp' directory. It seems that file is not uploaded in IIS.

Please don't offer me Apache helps because our customer wants to keep IIS. 🙁

Help me!!!

mithril

Hey Toni,

My suggestion is to check out the path string you're using to copy the uploaded file from the temp directory to the destination. For example, in a classified ads app I recently wrote, customer's could choose to upload pictures which would then be renamed and moved into a temp. upload directory pending ad approval by the site admin. I ran into the same thing you're describing. The problem was the way IIS reports system paths in the environment variables. I was using something like:

$final_dest = $DOCUMENT_ROOT . $temp_up_path . "image.jpg";

to create the path where $temp_up_root is defined in a settings file as something like:

$temp_up_path = "/temp/image_dir/";

Apache on Win32 reports $DOCUMENT_ROOT as "d:/inetpub/wwwroot" so this works (of course it works in *Nix as well). IIS on the other hand reports $DOCUMENT_ROOT as "d:\inetpub\wwwroot" so the mixing of front and backslashes of course caused a script failure. Yet another one of my pet peeves with M$, why do they feel the need to try and do stupid crap like using backslashes when all URL's and UNC's use forward?

<sigh>the monkey's are trying to infiltrate</sigh>.

Anyways, hope this helps you out!!

Cheers,

Geoff A. Virgo

ttunkka

Hi!

Main problem now is that file doesn't upload. I cannot see any .tmp files in current upload_tmp_dir.

mithril

Hmmm......

Actually the *.tmp file will be deleted as soon as the server finishing executing the script, so that's why you're not seeing it (assuming that the upload actually did occur). Check your <form> tag to make sure you're using the correct type. It should read something like:

Then place a call to phpinfo() on the target page. If the file has uploaded, somewhere towards the bottom of phpinfo()'s output (in the PHP Variables section) you should see a section on HTTP_POST_FILES['name of the form's file element']. This array should contain the name of the file you uploaded, it's type, it's size, and the name of the *.tmp file on the server. Try using $HTTP_POST_FILES[some_name][tmp_name] to copy the uploaded file into it's final location. You could also check to make sure that the file_uploads directive in php.ini is set to 'On'. If you don't have access to php.ini, try placing this call at the top of your script:

ini_set('file_uploads', 'On');

This may over-ride the master php.ini setting for this script. It may not work though since many admin's will disable the ini_set() function. Hope this helps!!!

Cheers,

Geoff A. Virgo

Anon

I can not find a way to get the DOCUMENT_ROOT variable from NT on IIS without setting it manually. Is there anyway to do this??

mithril

Paul,

How are you trying to call $DOCUMENT_ROOT? I've never had any trouble actually getting the var on IIS/NT. Of course it's reported using Win32 path backslashes instead of Unix/URL forward slashes, but that's a whole different thread🙂 Are you calling it in a function? It so, you have to make sure that you declare the var global after the function declaration or, better yet, pass it into the function as an argument. Hope this helps!!!

Cheers,

Geoff A. Virgo

Anon

I've tried simply accessing it via:
global $DOCUMENT_ROOT;

Then the value for $DOCUMENT_ROOT is null. Is there something I need to specify in the php.ini file? I've run into this problem doing clean CGI installs of PHP 4.04 on 2000 Server and NT 4 Server, both using IIS.

Any thoughts?

Thanks!!
Paul

mithril

Hey Paul,

Try using this:

$HTTP_SERVER_VARS["DOCUMENT_ROOT"]

What you could also do is call phpinfo() and see if that function gives you an alternate en_var to play with. I'm pretty sure it does, but for the life of me I can't remember what it is. Let me know if there's still no luck.

Cheers,

Geoff A. Virgo