It will accept 2047M Anything bigger breaks post data completely. You 
can only use GET variables.

we are using 64-bit ubuntu (jaunty and karmic) at archive.org, and php
v5.2.6 and v5.2.10 (respectively).  we are using fastcgi php-cgi
with nginx.

for us, with these 2 patches, we can get up to 8G posting to work
(haven't tried over 8GB 8-).

basically, they are about tracking the config setting/reading vars 
that are 32bits wide when they'd need 64bits, and similar for upload 
limit checking and reading.  

they prolly will not work with 32bit ubuntu immediately without some 
minor tweaking (since i started using long (8B on 64bit; 4B on 32bit) 
datatype and stuck with it instead of "long long" (8B on both)).  i'd 
be happy to try to extend the patches  to work on both 32bit and 64bit 
if there is interest.  (basically it took me awhile to figure these 
out and we are only running on 64bit so  i'd want an 
incentive/encouragement to do the extra work 8-)

http://www.archive.org/~tracey/downloads/patches/jaunty-64bit-post-
large-files.patch

http://www.archive.org/~tracey/downloads/patches/karmic-64bit-post-
large-files.patch

http://www.archive.org/~tracey/downloads/patches/jaunty-64bit-post-
large-files.patch-README.txt

The same problem was faced by me. It seems that PHP stops if size of file is above 2Gb (i.e. signed int). 
Will someone fix this issue?

Can someone add a patch for debian squeeze?

Do you plan to apply this patch ?
5.3 doesn't support file upload if the file is bigger than 2Gb.
It seem that 5.4 have the same limit.

It's probably too late for 5.4, but would be OK for trunk. The patch however 
needs to be cleaned up (no IGNORE vars, etc.) and changing signature for 
zend_atoi may not be safe if any code out there presumes it returns int (integer 
overflow). Also, no reason to use signed long there where we used unsigned long.

I was recently bitten by this bug too.  The patch needed a little updating for 
11.04 and I also found a couple of other issues.  1) Uploads only work if 
upload_max_filesize = 0 and 2) The $_FILES[*]['size'] value is an overflowed 
integer.  The attached patch fixes these issues.  I am currently in the process of 
re-rolling the patch against HEAD on master to get this in to upstream.

I have re-rolled the patch against HEAD (b4d078f18c950a4bf7e136443586e348bd54f40c) 
and attached it to this request.

In my opinion this is quite an issue. We faced it at an intranet side yesterday.
Due to the cast to int at https://github.com/php/php-src/blob/master/main/rfc1867.c#L901 it also has weird side effects, like setting 4G will equal 0 and disable the size check (see https://github.com/php/php-src/blob/master/main/rfc1867.c#L1031), 5G equal 1G etc.

Could you please add this patch? It MIGHT make seem PHP less an embarrassing 
language than it is already.

Sincerely,
The Internet

Newest Mailing List feedback applied.
Pull Request attached.
Please pull or comment in github or here.

The fix for this bug has been committed.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.

Fixed in master on x86_64

The patch only supports files up to 4GiB. I failed to upload larger files and only got the following message on all browsers:

> PHP Notice:  Missing mime boundary at the end of the data for file 51.dat in Unknown on line 0,

The CGI bug has been fixed; see http://git.php.net/?p=php-src.git;a=commit;h=8962f3ff0c76c5710f5e14d6f342f44498ff882b