Uploading files / tmp file creation

[BuhBompus]

OK. I don't know if this is a bug in PHP / LSAPI / LSWS , but here goes:

When uploading a file via a form to a .php , php says it saves the file in /tmp/php<random> whatever, and if I do the following, it creates the new file "test1.move" correctly.

move_uploaded_file($_FILES['filename1']['tmp_name'],'/home/picgame/tmp/test1.move');

The problem is, the filename in [tmp_name] does not exist, so I am thinking instead of php SAVING the file to the upload_dir like it should be, it is storing it and accessing it from RAM.

For a script I am working on (upload progress) , I need to be able to read the size of the file from the filesystem before it is finished and after it is finished without having to use move_uploaded_file.

Anybody have ANY ideas why php is not saving the file /tmp/phpRandomID to the drive as it is being uploaded?

 

[ts77]

its only saving the file there once the upload is finished.
thats a known issue in php and there have been some tries to change this with patches (search the php.internals-list for those tries) but no patch has made it into the core.
most upload-progress meters therefore are using perl to save the file which saves it while uploading.

 

[BuhBompus]

Yes , but the problem is once the upload is finished, it is NOT saving the file there, the only way to have it save the file is to use move_uploaded_file, then the file you move to will appear. The "file" you are copying from (tmp_name) does not exist on the servers HDD, so it must be storing it in RAM for some reason.

its only saving the file there once the upload is finished.
thats a known issue in php and there have been some tries to change this with patches (search the php.internals-list for those tries) but no patch has made it into the core.
most upload-progress meters therefore are using perl to save the file which saves it while uploading.

 

[ts77]

heh no, it *is* created. I did it many times and if you didn't move it, it appears there.
are you sure that you have the right permissions to *see* it?

 

[xing]

With regards to reading a pending upload (upload progress) check this thread:

http://www.litespeedtech.com/community/forum/showthread.php?t=402&highlight=upload+progress

As far as the tmp_file not created period on filesystem, I will attempt to duplicate this problem via PHP 5.1.4 + LSAPI and let you guys know my findings.

And btw...BB, if you can share a code snippet of your upload script which confirms that the tmp_file is not being created, that would help also. So we can pinpoint the problem.

 

[BuhBompus]

heh no, it *is* created. I did it many times and if you didn't move it, it appears there.
are you sure that you have the right permissions to *see* it?

Hate to break your bubble, but *no* it is not created am I am logged in as root and a ls -a shows it not being there AT ALL if I do not use move_uploaded_file, if I use move_uploaded_file, the moved file "test1.move" appears almost instantly, but the tmp file is still not there and never was unless my filesystem is playing tricks on me.

For the record I am using PHP 5.1.4 w/ LSAPI 2.0

 

[BuhBompus]

With regards to reading a pending upload (upload progress) check this thread:

http://www.litespeedtech.com/community/forum/showthread.php?t=402&highlight=upload+progress

Ok.. I noticed i tried it with a php patch but evidently lsws isn't forwarding the request to the multipart post_handler in rfc8167.c until the ENTIRE upload is completed... Is this correct?

If this is the case, it *may* be created the tmp_file but not being visible long enough before the script ends to show up (cause on end of script execution php will remove the tmp_file immediately).. If this is what is going on, there would be no way to check the progress of uploads unless you add support to handle "multipart/form-data" differently. Correct me if I am wrong.

 

[xing]

Correct, lsws will only forward request to backend after receiving the entire request, including body. Upload progress indicators/patches doest not current work with litespeed due to this feature.

There is a "receive" memory buffer setting in which Lsws uses for all requests. Lsws will use on disk buffer if the entire upload cannot be fit into the in memory receive buffer.

So a tip to improve uploads speeds and site with large post operations, is to increase the "receive" buffer.

 

[xing]

The temp files are being created. They are just created/destroyed very fast.

When into one of our beta tester's live file-upload server and did a simple repeat cli of:

cd /tmp/uploads/
ls php*

It took quite a few tries to finally reveal:

php5H2YTt

Figure this test method was quicker than coding up a script.

Setup:

PHP 5.1.4 + PHP LSAPI 2.0 + LSWS 2.1.15.

If you do a file read on the tmp_file before the move command, it should work.

 

[BuhBompus]

The temp files are being created. They are just created/destroyed very fast.
If you do a file read on the tmp_file before the move command, it should work.

You are correct. I guess I will have to live with using ajax/js to disable the upload button and display something that shows that it is working on the upload progress and then display a message once it is done.

Thanks for the quick replies!

 

[kandon]

tmp_name destroyed too quickly

Do you have a code example on how to read the file instead of relying on the tmp_name file?