On Drupal 6.16, running on a 32-bit Intel box and Fedora 12 (which may be relevant below):
I'm working on a site whose users will be loading some large files, perhaps a couple of gigabytes. I've set up my PHP installation such that POST_MAX_SIZE and UPLOAD_MAX_FILESIZE are both set to "2G". When I try to create a content type field (of pretty much any type, it seems), I find an error message like the following in my log files:
PHP Warning: Unknown: POST Content-Length of 1468 bytes exceeds the limit of -2147483648 bytes in Unknown on line 0, referer: <referer page goes here>
So, two issues:
* In this situation, the attempt to create the field simply fails -- no message, no nothing. It would of course be a Good Thing if the content type code could detect the problem and explain what's going on (especially since the PHP message isn't showing up on the page returned by Drupal, even though I currently have PHP's ERROR_REPORTING set to E_ALL).
* Regardless, I'd still like to be able to have a max 2GB file size, but my current guess (I'm skating on the edge of my competence here) is that I just can't, on a 32-bit machine anyway, since the poor bugger can't deal with an integer that large. Is this the case, and I'll just have to live with a smaller file size limit, or is there some way around it? Thanks!
Comments
=-=
shouldn't it be 2000M ?
I currently have the limits
I currently have the limits set in php.ini to "1G"; it's working fine, and phpinfo() properly shows the limits as 1G. So I don't think that's it; I'm also happy to avoid the whole thing about 2G vs 2000M vs 2048M... :)
=-=
I was asking for my knowledge. I was unaware one could use G nor of a "thing" with reference to 2000M vs 2048M
As you guessed you are
As you guessed you are running the limits of integers, no way around it. Also, not set POST_MAX_SIZE and UPLOAD_MAX_FILE to the same value can cause problems, POST_MAX_SIZE should be larger to account for other possible fields.
Stupid mathematics. I blame
Stupid mathematics. I blame Newton.
Still, it would be nice if the content type code could fail a little more transparently. Any content type folks around?
BTW, good point about the
BTW, good point about the differences between the parameters. Thx!
I believe this is not
I believe this is not possible using PHP. See:
http://www.php.net/manual/en/ini.core.php#ini.post-max-size
quote:
"post_max_size integer
Sets max size of post data allowed. This setting also affects file upload. To upload large files, this value must be larger than upload_max_filesize. If memory limit is enabled by your configure script, memory_limit also affects file uploading. Generally speaking, memory_limit should be larger than post_max_size."
That is the reason that modules such as http://drupal.org/project/swfupload were created, to bypass PHP's upload mechanism.
There are commercial products out there with a similar approach, using either flash or java to avoid PHP's limitations, cutting chunks etc.
To test this assertion, have you managed to upload, say, a 200MB file while having a lower memory_limit?
it seems to be an issue that
it seems to be an issue that most browsers do not allow uploads > 2GB (although opera should work)
also flash has limitations. officially adobe only supports 100MB file uploads with flash
see here for a discussion about this topic: http://swfupload.org/forum/generaldiscussion/584
but theoretically swfupload should handle even larger files (4GB ?) so i will give it a try and see if that works...
another option would be using ftp & mediamover but i try to avoid that, because users often have problems when they have to leave the browser for vertain tasks..
.
This is not just a browser issue. Notice what nevets said.
PHP's upload_max_size is an integer number.
http://php.net/manual/en/language.types.integer.php
quote:
The size of an integer is platform-dependent, although a maximum value of about two billion is the usual value (that's 32 bits signed). 64-bit platforms usually have a maximum value of about 9E18. PHP does not support unsigned integer s.
...snip...
Integer overflow: If PHP encounters a number beyond the bounds of the integer type, it will be interpreted as a float instead.
...snip...
When converting from float to integer , the number will be rounded towards zero. If the float is beyond the boundaries of integer (usually +/- 2.15e+9 = 2^31 on 32-bit platforms and +/- 9.22e+18 = 2^63 on 64-bit platforms), the result is undefined.
just for the record. i am
just for the record. i am using now a combination of ftp and filefield sources ( http://drupal.org/project/filefield_sources )
made possible by a patch provided in this issue #438940: Add ability to use file uploaded via FTP
i've tried it with files > 5GB and it works great.