4images Forum & Community
4images Issues / Ausgaben => Discussion & Troubleshooting => Topic started by: siredgar on September 21, 2009, 10:37:04 PM
-
I have a brand new installation of 1. 7. 7 at
http://files.arcadecontrols.com/
(First, a thank you to the authors and everyone who has helped on the forums. Any problems or desires I've had I've been able to figure out by reading other posts. Thanks!)
I have a problem with . zip files. Most (but not all) of the zip files on my server will not download properly. They are corrupt when downloaded. However, when I look at them on the server the . zip file is not corrupt. If you directly download the file using http the file is not corrupt. If you download the same file from the download. php 4images script, the file is corrupt.
All files are stored locally, there are no remote files. I am not using the zip download button, I am using the standard download button. The files are previously zipped before being uploaded to my server. Here I have a few examples:
File: mrotate2. zip -- in the "Miscellaneous" category, which is directory number 27. Actual file name on disk is setup. zip. 403kb
URL: http://files.arcadecontrols.com/details.php?image_id=3431
4images script download link: http://files.arcadecontrols.com/download.php?image_id=3431
Direct download link: http://files.arcadecontrols.com/data/media/27/setup.zip
=========
Using the 4images download. php script, the file is corrupt
using the direct link, the file is not corrupt
Both links use the http protocol, not FTP.
File: multipac. zip -- in the "Arcade Manuals and Schematics" category, which is directory number 4. Actual file name on disk is multipac. zip. 500Kb.
URL: http://files.arcadecontrols.com/details.php?image_id=2426
4images script download link: http://files.arcadecontrols.com/download.php?image_id=2426
Direct download link: http://files.arcadecontrols.com/data/media/4/multipac.zip
===========
Using the 4images download. php script, the file is corrupt
Using the direct link, the file is not corrupt
Both links use the http protocol, not FTP.
Strangely enough, the following zip file works properly.
File: sinistar-paint-codes. zip -- in the "Paint Codes" category, which is directory number 14. Actual file name is sinistar-paint-codes. zip. 8. 8Kb.
URL: http://files.arcadecontrols.com/details.php?image_id=3430
4images script download link: http://files.arcadecontrols.com/download.php?image_id=3430
Direct down load link: http://files.arcadecontrols.com/data/media/14/sinistar-paint-codes.zip
===========
Using the 4images download. php script, the file is not corrupt
Using the direct link, the file is not corrupt
Both links use the http protocol, not FTP.
--------------------------------
I thought maybe file size was a factor, but the following two tests don't seem to really agree:
File: logo. zip - 13Kb
download.php download: http://files.arcadecontrols.com/download.php?image_id=3485 = corrupt
direct download: http://files.arcadecontrols.com/data/media/27/logo.zip = working
File: test2. zip - 189b
download.php download: http://files.arcadecontrols.com/download.php?image_id=3483 = working
direct download: http://files.arcadecontrols.com/data/media/27/test2.zip = working
----------------------------------------------------
----------------------------------------------------
So I am at a loss. Any suggestions or tips? Help is much appreciated!
--- John St. Clair
Build Your Own Arcade Controls
-
try open corrupted file in notepad.
-
try open corrupted file in notepad.
I did open one in notepad. The header looked OK to me:
PK Ȁ5;Qע2 3 logo.gifPM!!$5"`@ޑ^ Q (AB/*h( h Am b{?o+s3;gima`_
: 04ZPDȊJ*ʪʪYU-CZEUP됡YCC#s&65>?J
'k)ZC<0br(P!b
The footer looked like this:
*j^lo2cLMoͿhPK Ȁ5;Qע2 3 logo.
So I don't see anything obvious being added to the front/back of the file.
-
interesting, the corrupted files are missing 25 bytes at the end...
is gzip compression turned on on your server (see zlib.output_compression in phpinfo in ACP) or in 4images itself (see "Use GZip compression" in settings)?
I just double checked download.php and couldn't find anything that could possible cause this. it uses PHP's built in functions filesize() to detect filesize and readfile() to read and output file's content...At this point all I could suspect is it's server related issue...
-
interesting, the corrupted files are missing 25 bytes at the end. . .
is gzip compression turned on on your server (see zlib. output_compression in phpinfo in ACP) or in 4images itself (see "Use GZip compression" in settings)?
I just double checked download. php and couldn't find anything that could possible cause this. it uses PHP's built in functions filesize() to detect filesize and readfile() to read and output file's content. . . At this point all I could suspect is it's server related issue. . .
I will check. Should gzip be turned on or off?
If it was a server issue why would it allow them to be downloaded directly? I was thinking perhaps a php issue but what I don't know :)
-------------------
phpinfo says:
zlib. output_compression On On
gzip is set to "no" in 4images settings.
-
Ok, I just reproduced this on my local server. It's indeed conflicts with zlib.output_compression
The work around is to add this line in download.php, below <?php
@ini_set('zlib.output_compression', 'Off');
-
Ok, I just reproduced this on my local server. It's indeed conflicts with zlib. output_compression
The work around is to add this line in download. php, below <?php
@ini_set('zlib. output_compression', 'Off');
Excellent, thank you! This has resolved the problem! Very much appreciated!
I'm curious as to the technical details. zlib compression is on in my default php installation on the server, but this turns it off for just this script instance, right? Are there any drawbacks to not having zlib compression turned on?
Thanks again!
--- John
-
Yes, you are correct. The problem with zlib compression, is that php/webserver itself will compress the output, which means, from within the script there is no way of knowing what final size will be of the outputed data.
The only other possible solution for this would be removing Content-Length header, which would be a minor problem for the client, as it wont be able see how much time/data left for the file to download.
-
Yes, you are correct. The problem with zlib compression, is that php/webserver itself will compress the output, which means, from within the script there is no way of knowing what final size will be of the outputed data.
The only other possible solution for this would be removing Content-Length header, which would be a minor problem for the client, as it wont be able see how much time/data left for the file to download.
Ah, ok! Thanks again :)
-
Hi,
i add @ini_set('zlib.output_compression', 'Off'); in Download.php , but i'm still have problem..
also i remove
header("Content-Length: ".$filesize."\n\n");
and it's not work , i have 4image 1.7.10
any help
-------------------------------------------------------------------------
That's my problem , I can't wait and still keep trying until i fix it.. Here is how with new version for 4images 1.7.10
go to include/zip.php and search for this code , located on line 200
@ini_set('zlib.output_compression', '0');
and change it to:
@ini_set('zlib.output_compression', '1');
save it, and that's will fix the problem.