memory_limit is truncating ZipCart downloads (not zip creation!)
|
filip_tc
Joined: 2006-05-25
Posts: 29 |
Posted: Wed, 2009-11-11 22:47
|
|
When using the ZipCart to generate and download a ~500Mb zip archive (which displays with its correct file size in the browser), it starts downloading fine but always finishes at 95.4Mb. The resulting zip is corrupted (/incomplete). Any chance this is ZipCart's fault? If not, is it a server-limit fault? (Which limit?) |
|
| Login or register to post comments |
Posts: 29
I just came to the conclusion that:
100000000 bytes = ~95.4 megabytes (95,38MB)
so it would seem like a really big coincidence for it to not be a limit issue... But which limit?? The guys from my hostings didn't seem to know about any limit (or at least so they claimed).
Posts: 29
I uploaded a 150Mb file to my server just to check and it downloads fine... I'm confused....
Posts: 29
So, I found some interesting new info. My hosting team said the following:
"If a php script is handling the download itself through the gallery2 software it would be terminated by a php's 'max_execution_time' of 30s. This may be why you can download it directly from the server, but not through the image gallery software."
Please correct me if I'm getting ahead of myself but, obviously, some kind of script must be dealing with the zip file, since it's being generated outside of the public www folder and yet somehow being re-piped to the user via http. And that script must be executing throughout the entire download for the file's integrity's sake. So the big question is (if I am on the right path):
Can this behavior be avoided / worked around?
Posts: 29
Ignore my last message. I was wrong.
Why not look at the apache logs? I did and check this:
Ok, is there a way around that?
Posts: 3113
Have your host allow more memory.
In this day and age memory/bandwidth/storage are cheap.
you can also try adding:
@ini_set('memory_limit', '48M');to gallery2/config.php just after @ini_set('display_errors', 0);
if your host allows such things, you can extend execution time the same way.
-s
FlashYourWeb and Your Gallery with The E2 XML Media Player for Gallery2
Posts: 29
The limit is already at 128M and hosting doesn't allow ini_set changes...
Posts: 3113
Smaller zips, or more memory.
134217728 bytes is 128MB
-s
FlashYourWeb and Your Gallery with The E2 XML Media Player for Gallery2
Posts: 10934
If you want PHP to create or deal with a 512MB zip file you're going to need to allow AT LEAST 512MB of memory for PHP.
I think, suprsidr can correct me if needed, the deal is that the zip file may in fact be getting created, however, ALL file downloads (your images, zips, etc) are run through Gallery and it's not a direct download. But instead goes through Gallery's "image firewall" and is served up by PHP and not a direct file link to download from your web server (who wouldn't care what size the file is unless your host has some asinine restrictive module installed for the web server)
It would either take more investigating or someone who knows to figure out exactly where, but either way as suprsidr stated you need more memory to deal with large files.
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 29
I think that's exactly the problem. But I guess I'm stuck for now because limits on this host (and my current hosting plan) are pretty static...