go to bug id or search bugs for
Progress for uploads > 2 GB break. Even though we're using the uploadprogress on 64bit machines. Any chance you can solve this with the next update?
Nowadays more modern browsers have the capability to upload files larger than 2GB, and this limitation should really be removed from the uploadprogress module to be ready for the future.
Feedback is highly appreciated.
Add a Patch
Add a Pull Request
This problem also happens when uploading multiple files that are more than 2GB combined. bytes_total is negative and est_sec is sometimes a negative number and other times a positive number. Casting these numbers to an abs value (removing the negative sign) does not yield correct results.
Noone here that can supply a patch or some fix for this issue? I will PayPal 250 USD to the first person that supplies a fix :)
assign the 250 USD to author. :)
Where is the fix, then? :)
may be due to the read_byte variable in
it was declared to be int, change it to size_t might fix this problem(not sure,
This is a problem with PHP. I am using Debian 32bit with PHP 5.3.8 and see this
problem. PHP freaks out when you try to change the post_max_size and
upload_max_filesize greater than 2047M. Once it gets to 2048M, POSTs have
problems. You will see errors in the logs pointing to negative numbers.
I tried to compile PHP with a patch from
http://weblog.failure.net/archives/2011/03/uploading_files.html but the resulting
binaries have problems POSTing even with post_max_size and upload_max_filesize
less than 2048M.
The patch listed above supposedly works on 64bit linux. I am not sure if we can
move to 64bit on that server so that is not an option for me.
If somebody can get this to work properly on 32bit systems, that would be
We have manage to remove the negative value from the number returned by the
We had to make the read_byte variable an unsigned long. We found that size_t was
on 32bits wide but thank you to laruence for the suggestion.
However, the number returned for total bytes is still way off what it should be,
which then puts the time out by quite a bit as well. Does anyone have any idea why
this might be.
Total bytes is based on content length, which is wrong with uploads > 4GB. Should be fixed in PHP 5.4 according to the release notes. See this bug:
This bug is still present in uploadprogress 126.96.36.199.
PHP 5.4.9-4ubuntu2.1 (cli) (built: Jun 11 2013 13:08:51)
Output from: php -r 'echo PHP_INT_MAX;'
So there shouldn't be a problem with int length.
Does anyone have any solution? Or patch or...
Tested on x64.
uploadprogress.c line 216
$d - signed int (-2.147.483.648 - 2.147.483.648), 2GB ~ 2.147.483.648
$lu - unsigned long
Those changes almost makes everything work. The uploadprogress gets reported properly. But as soon as the upload reaches > 2gb:
Returns nothing. Do you have any clue on how to solve this?
@peter at kahn
what php version u have?
php 5.4.3 works fine.
On php 5.3.3 I see problem with uploadprogress "e_data->content_length" because old PHP versions have a "bug" with content_length (atoi() use):
./sapi/apache2filter/sapi_apache2.c: SG(request_info).content_length = (content_length ? atoi(content_length) : 0);
On newer version, I take a look in 5.3.27, PHP use correct atol().
also tested on php 5.3.28, works fine.
Hmm, strange.I'm using php 5.4.9 and it works up to 2gb after that the uploaded size increases to:
and then keeps counting. Then after the size goes over 4gb the uploaded value changes randomly again. Not sure why.
This package has not had any releases for 6 years, so I'm gonna suspend it, any new maintainer that decides to pick this up can re-open this ticket.