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 
uploadprogress_php_rfc1867_file(uploadprogress.c) 

it was declared to be int,  change it to size_t might fix this problem(not sure, 
didn't test).

thanks

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 
https://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 
fantastic.

We have manage to remove the negative value from the number returned by the 
uploadprogress extension.

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:
https://bugs.php.net/bug.php?id=60205

This bug is still present in uploadprogress 1.0.3.1.

I'm running:
PHP 5.4.9-4ubuntu2.1 (cli) (built: Jun 11 2013 13:08:51)

Output from: php -r 'echo PHP_INT_MAX;'
9223372036854775807

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
was:
fprintf(F, "upload_id=%s\nfieldname=%s\nfilename=%s\ntime_start=%d\ntime_last=%d\nspeed_average=%d\nspeed_last=%d\nbytes_uploaded=%d\nbytes_total=%d\nfiles_uploaded=%d\nest_sec=%d\n",

must be:
fprintf(F, "upload_id=%s\nfieldname=%s\nfilename=%s\ntime_start=%d\ntime_last=%d\nspeed_average=%d\nspeed_last=%d\nbytes_uploaded=%lu\nbytes_total=%lu\nfiles_uploaded=%d\nest_sec=%d\n",

reason:
$d - signed int (-2.147.483.648 - 2.147.483.648), 2GB ~ 2.147.483.648
$lu - unsigned long

@bogdanov
Thanks!
Those changes almost makes everything work. The uploadprogress gets reported properly. But as soon as the upload reaches > 2gb:

uploadprogress_get_info();

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:

18446744072977470545 

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.

The latest build from the ondrej ppa is working for me. Its version 1.1.3-3 on Ubuntu Focal I think. I changed

int read_bytes;

to

unsigned long read_bytes;

I was able to get upload progress for a 5 GB file all the way to 100%.

The variable is still declared as int[1]; changing to unsigned
long would not be okay for Windows; it should likely be size_t.
But signedness issues would have to thoroughly checked.

[1] <https://github.com/php/pecl-php-uploadprogress/blob/9ba77bc727ff3b47abfe13d60c1eb6f105be1485/uploadprogress.c#L81>