Forum Moderators: coopster
I've developed a site that requires the owner to upload images. We had some hiccups at first on the live server due to safe_mode and open_basedir restrictions - sometimes images would upload, other times not;we got around that by setting the tmp dir local to the site:
/usr/www/mysite.com/:/var/tmp
This worked. For months. Now the problem has returned.
Sometimes images upload, other times not. I am not seeing any error messages.
When it does fail, the $_FILES array data are inserted into the database, but the BLOB data seems to be lost.
Only once have I not been able to upload from work, while the client has not been able to do so for a week now.
I'm looking into firewalls and antivirus progs as a possible issue, can anyone suggest anything else?
ISP issues? Caching issues?
How about doing a strlen() on the variable before it is inserted. If zero, then dump an error message.
Thanks for the reply!
- Exceeded your storage quota.
- Hard disk full.
- Improper permissions on destination folder
Thing is, I can upload to the remote server from my computer at home through the same interface.
I assume you are opening the temporary file, reading it into a variable, then inserting the resulting string into the database?
Exactly.
Is there anything in the database at all in the BLOB field?
Using phpmyAdmin, I get '[BLOB - 0 KB]'. After an unsuccessful insertion, the table shows overhead equivalent to the filesize.
How about doing a strlen() on the variable before it is inserted. If zero, then dump an error message.
Nice. I'll give it a try.
Thanks!
How big is the uploaded file?
Is your form a method="post" using <input type="file"... to upload?
Check the filesize of the temporary file. Is the file even making it to the temp directory?
Do a phpinfo() command and look for 'post_max_size' if set to too low of a value it will probably fail the upload.
I know, all questions. We've gotta find where the failure is before it can be fixed! ;)
I've built an interface for a customer that allows him to upload site graphics, though I move the files and just reference them in the database. I've not had any such random problems with uploading and moving files once I got it working in the first place.
When you upload from home, is it the same file that is failing from other places?
Yes.
How big is the uploaded file?
42.7 kb
Is your form a method="post" using <input type="file"... to upload?
<form method="post" action="myscript.php" enctype="multipart/form-data">
<input type="hidden" name="MAX_FILE_SIZE" value="50000" />
<ul>
<li>Image 1<input type="file" name="binFile1" /></li>
<li>Image 2<input type="file" name="binFile2" /></li>
<li>Image 3<input type="file" name="binFile3" /></li>
</ul>
<input class="forms" type="submit" value="Upload" />
</form>
Do a phpinfo() command and look for 'post_max_size' if set to too low of a value it will probably fail the upload.
The value set is 204800.
How about doing a strlen() on the variable before it is inserted. If zero, then dump an error message.
I didn't give this a go yet, but I had done something similar when troubleshooting earlier. The file data comes from here:
$data = addslashes(fread(fopen($temp, "rb"), filesize($temp)));
What I did was echo $data; a successful upload echoed all of the blob data, an unsuccessful one echoed nothing.
I'm off to try the strlen right now.
I've built an interface for a customer that allows him to upload site graphics, though I move the files and just reference them in the database.
I rewrote the script a week ago to do it in the same way, but for some reason it lost the file this way as well.
I uploaded the old code, 'cause I thought it worked. Now I'm realizing that something else may have been 'broken'.
Shows a value when the upload works. I have no data yet for when it doesn't work.
Interesting
The one time it failed for me, I had it echoing the sql statement, which is built like this:
$sql = "INSERT INTO $image_table ";
$sql .= "(description, bin_data, filename, filesize, filetype, owner, $var_num) ";
$sql .= "VALUES ('$strDescription', '$data', ";
$sql .= " '$name', '$size', '$type', '$CURRENT_USER', '$var_in')";
if (!mysql_query ($sql, $link) ){
die (mysql_error());
}
What it echoed was everything but the $data. $data was empty.
Does this help pinpoint things a bit?
You may want to echo out if the file exists. Then echo out the filesize. Then echo out the $data var to make sure it read the file properly. I'm sure one of those will fail and then you can figure out the problem from there.
<added>
While this is nice neat code: $data = addslashes(fread(fopen($temp, "rb"), filesize($temp)));
It doesn't allow for errors at each level so break it up a bit.
</added>
JAG
$data = addslashes(fread(fopen($temp, "rb"), filesize($temp)));What I did was echo $data; a successful upload echoed all of the blob data, an unsuccessful one echoed nothing.
What this tells me is that the problem is in getting the data to the server in the first place. The insert into the database is not even involved.
One thing I would do is to increase the MAX_FILE_SIZE value. I'm not sure if this value is to be considered a total size or a individual size, but since it is interpreted by the browser, it's better to play safe.
Also, your code above that reads the data is prone to problems. There is no error checking at all, so any error will just propagate through with no warning at all. I'd change the code to this:
if (FALSE!=== ($fh = fopen($temp,'rb'))) {
$data = addslashes(fread($fh,filesize($temp));
fclose($fh);
} else {
echo "ERROR opening file {$temp}";
}
I would also dump the $_FILES array to see if the upload is even occurring correctly. Do a:
printf("<pre>");print_r($_FILES);printf("</pre>");
Still digesting your message, but quickly...
Check the ['binFileX']['size'] and the ['binFileX']['error'] elements to see if the file even made it to the server.
**Values are input in the dbase table for filename, filesize, and filetype - the blob field shows up empty, but it seems that the table reserves the space for the blob, as after an unsuccessful upload the table has an overhead equal to the value of the blob.
HTH?
Now, back to digest your post...
You may want to echo out if the file exists. Then echo out the filesize. Then echo out the $data var to make sure it read the file properly. I'm sure one of those will fail and then you can figure out the problem from there.
When the upload fails, it seems like $data is what is missing (see ** this message above the horizontal rule).
I'm having trouble with your code there, but I get what you and justageek are saying. I'll break it up and get the client to try and upload something and see what errors are found.
<added>
While trying to get in touch with the 'troubled' client, I spoke with another who is running the same script on the same serevr and they metioned that they have had no problems...?
While trying to get in touch with the 'troubled' client, I spoke with another who is running the same script on the same serevr and they metioned that they have had no problems...?
Different browsers?
JAG
Different browsers?
Not sure, but they've recently installed Norton Antivirus and subscribed to an online streaming music service. We're waiting for their 'techie' to call us and let us know if they've also installed a port blocking firewall.....
Thanks a lot for your help. If anything (so far) I've learnt PHP things here...
I'm having trouble with your code there,
$data = addslashes(fread($fh,filesize($temp)));
What it echoed was everything but the $data. $data was empty.Does this help pinpoint things a bit?
It actually confuses me greatly! :(
Because in another post you said:
Values are input in the dbase table for filename, filesize, and filetype - the blob field shows up empty, but it seems that the table reserves the space for the blob, as after an unsuccessful upload the table has an overhead equal to the value of the blob.
Which makes no sense at all. If $data is empty, how does MySQL how much space to reserve?
How about using mysql_escape_string() in place of addslashes().
BTW, a port blocking firewall shouldn't be able to affect POST data as POST data is sent using the same port that the HTTP request goes through.
Sorry, I didn't close one of the paren's
Yeah, I caught that, but was getting an 'extra =' on this line:
if (FALSE!=== ($fh = fopen($temp,'rb'))) { Which makes no sense at all. If $data is empty, how does MySQL how much space to reserve?
Thats a great question. And get this, here's the code that I used:
$fh = fopen($temp, "rb");
if ($fh == FALSE) {echo "ERROR opening file {$temp}";}
else {$data = addslashes(fread($fh,filesize($temp)));
fclose($fh); }
Just to test things, I hardcoded in a value for $temp after it gets the value from the $_FILES array. The result was an exact duplication of what is observed when the client tries to upload a file and it fails. The appropriate $_FILES data is stored in the database, the BLOB field is empty, yet there is an overhead on the table now of exactly the size that the image is supposed to be.
I'm going to go and try this again, just to make sure...
I'm going to go and try this again, just to make sure...
Yeah. Forget about that. Sorry. Not the case.
<update>
Okay, the way I tested it, you don't get the overhead. But on the live server, where the client is uploading the data, you get this:
[BLOB - 0 Bytes] Baņo.jpg 24069 image/pjpeg
for example, and the table developes an overhead.
Listen bitbanger,
It's the end of the night here. I'm going to try some of your changes tomorrow and have the client try uploading some images. I'll double check everything that I've postulated and report back here.
Thanks a lot for your help.
Yeah, I caught that, but was getting an 'extra =' on this line:if (FALSE!=== ($fh = fopen($temp,'rb'))) {
if (FALSE!== ($fh = fopen($temp,'rb'))) {
I'd still suggest dumping the $_FILES array. It might be that the 'tmp_name' element might be empty due to a communication error. Also, an 'echo strlen($data);' would be interesting when a failure occurs.
If your PHP version is > 4.2.0, check the value of the 'error' element. If it is not '0' then there was a problem with the upload.
Is your 'problem client' on a slow connection? Could there be a timeout issue?
Sorry about the delay. Had a couple of other issues to settle and the client was outta the office.
So, I took both of your advice and simplified the code. I also had it spit out some information. Of note, the whole overhead theory was bogus. Sorry, too many little tests and stuff got me mixed up.
Anyway, here's the results of the client uploading:
"FILES" => Filename: Baņo.jpg, Filetype: image/pjpeg, Temp Filename:
/tmp/phpclKBuI, Filesize: 24069ERROR opening file /tmp/phpclKBuI
So it would seem that once up there it loses access to the file, no?
So it would seem that once up there it loses access to the file, no?
It would seem that way. The question now is why? Permissions? File locked? File does not exist anymore? I'm thinking the file does not exist anymore. If you don't do something with the file it will go away. I usually rename the file and move it immediately to prevent this.
JAG
If you don't do something with the file it will go away. I usually rename the file and move it immediately to prevent this.
Okay,
1. Well the file should be inserted right then and there into the dbase, no?
2. Why does it only happen when *they* upload files? (I think this is a tough one).
3. How do you 'rename the file and move it immediately to prevent this'?
Thanks again... mipapage
Of note, the whole overhead theory was bogus.
So it would seem that once up there it loses access to the file, no?
What version of PHP are you using?
What browser is the 'problem' client using?
I don't see an error field in the $_FILES data. Is there one?
The source filename has an accent mark in it. Is this consistant across all upload failures?
I would guess that the file was never completely received at the server.
$imagedir = "path_where_to_save_file";
$dest_file = $imagedir.$HTTP_POST_FILES['your_var_name_here']['name'];
move_uploaded_file($HTTP_POST_FILES['your_var_name_here']['tmp_name'], $dest_file);
As you said though, the fact that you are trying to put the file in the db right away should work. The thing that gets me is that if the file did not exist then you should not see any values such as the file size in your files var. Since you see a size of 24069 as you said in one of your posts then the file must have existed at one time. That's why I think it is going away somehow before you have a chance to read it.
JAG
What version of PHP are you using?
What browser is the 'problem' client using?
I don't see an error field in the $_FILES data. Is there one?
My dumbass misktake. I had it for earlier tests and the code returned '0'.
The source filename has an accent mark in it. Is this consistant across all upload failures?
No, I checked into that. What I thought was a 'EUREKA!' moment turned into a 'damn'.
I would guess that the file was never completely received at the server.
<outburst> But WHY WHY WHY? Oh for the love of pete, why? </outburst>
I just do something like:
Yeah, I tried that and it didn't work - not even here from the office.
Thanks you two. We're still waiting to hear from their 'admin' guy. Looks like I'll have to pick this up again on Monday. Until then have a great weekend... I really really appreciate all the help!
As a possibility, I'd look for your script timing out.
Also try to upload a 2-300K file from your location. See if you can get a reproducable case locally.
Ok, getting an error result of '0'...
Okay. I can confirm that the error result was zero. I have the entire $_FILES array stored in the db. What I quoted earlier was what I had echoed on the screen for the client to send me.
As a possibility, I'd look for your script timing out.Also try to upload a 2-300K file from your location. See if you can get a reproducable case locally.
I did try a large file, and when it times out it takes no action and just returns to the main page that the script is on. For example, the script is on 'myscript.php' but the image upload form is on 'myscript.php?screen=upload_image'. When it times out it returns to 'myscript.php'.
I also tried setting the max file size low and uploading a large image. The result was that nothing was uploaded, and the only value in $_FILES was [name].
If possible, check the web server to see if the '/tmp' directory is on a partition that is close to being full. If the problem is somewhat random, it is possible that the partition lacks the space temporarilly to accept the file.
We've checked most of the obvious, and not so obvious, issues it could be. The problems is going to turn out to be something very subtle.
I assume that you are accepting more form variables than just these files. Can you move the file handling so that it is the first thing processed. It's possibe that you are exceeding max_execution_time causing the file to be deleted.
I would also add the following line at the head of your script.
$old_level error_reporting ( E_ALL );
This may show something. I'd only set this level for debugging purposes though.
Is this error completely reproducable? Does it always fail for your 'problem client' or can this client upload some files correctly?
Always with the client, only sometimes with us here at work, and that's a new thing, and I think we've had a Eureka! moment:
When the image uploads, it reports this:
"FILES" => Filename: imagebaņo4a.jpe,
Filetype: image/pjpeg, Temp Filename:
/var/tmp/php9thld3, Filesize: 43715, Error: 0
TempFileSize: 44724
When it doesn't, it reports this:
"FILES" => Filename: PANORAMA-II.jpg,
Filetype: image/pjpeg, Temp Filename:
/tmp/phpGvLor6, Filesize: 14213, Error: 0
ERROR opening file /tmp/phpGvLor6 - Size
Here is what is set in the httpd.conf file for the server:
php_admin_value open_basedir
/usr/www/mycurrentheadache.com/:/var/tmp
I can see that something is up here but not figure it out, 'cause I'm a php 'n Apache rookie. Any ideas?
$old_level error_reporting ( E_ALL );
All I can say to that is 'OUCH!'. I guess I have to do some debugging?
Not everything that gets reported is necessarily an error, but I'd look at the root causes anyway. Typically when I code I like to have completely clean code whenever possible. Sometimes even warnings can bite you in the butt.
As far as the /var/tmp and /tmp issue. I think that your hosting provider needs to look into the issue.
