2

Possible Duplicate:
Dynamically created zip files by ZipStream in PHP won't open in OSX

I'm using PHP ZipArchive to allow website users to combine a few files into a zip file, and then download them. It works perfectly on the Fedora linux computer I'm running it on. But if I download the files using my Mac laptop the files will not unzip, double clicking creates a cpgz file. Double clicking the cpgz file creates another cpgz, etc etc.

Going by a google search the zip-cpgz loop looks like it is a pretty common problem, but almost all the solutions suggest that the original file was poorly formatted; a zip of a non-existant initial file, a zip produced by a windows machine with a different file ending, things like that. I don't think that's the case with mine because it works fine on my Linux machine.

Opening the zip file in the terminal using unzip works, though gives the warning

warning [filename.zip]: 3 extra bytes at beginning or within zipfile (attempting to process anyway)

I would prefer not to tell users to use the terminal though, if I can avoid it.

Here's a link to one of the files, I can't provide a link to the website I'm operating, it's not up and running yet. The file should contain 8 ascii files (they're surface temperatures for a site on the surface of Mars).

http://eddybarratt.co.uk/wp-content/uploads/2012/06/files_run0000008.zip

Community
  • 1
  • 1
EddyTheB
  • 3,100
  • 4
  • 23
  • 32
  • That other question is for Zip Stream, it suggests a reason why ZipArchive isn't working, but there's suggestion for how to fix it. – EddyTheB Jun 04 '12 at 22:10
  • this is an old question and is closed, but I have possible answer. I had the same problem when downloading a dynamic zip. The problem was that there was debug text being printed before the `echo $zip`, creating a malformed file, that WinRAR ignores but Archive Utility don't. In this case the three bytes are probably the BOM from an utf8 source file. If someone has this problem, check the .zip file with an editor, it must start with PK, nothing else before. – Einacio May 05 '16 at 20:28

2 Answers2

1

An alternative to using PHP's ZipArchive class, which may provide better results, is the PCL Zip library. We use it in a custom-built CMS as a fallback when PHP's ZipArchive isn't available on a user's hosting account. Here's an example of how we're using it:

if ( class_exists('ZipArchive') ) {
    ... zip up the files with the PHP ZipArchive class...
} else {
    require_once('pclzip.lib.php');
    $pclZip = new PclZip($destination);
    $pclZip->create($files, PCLZIP_OPT_REMOVE_ALL_PATH);
    return file_exists($destination);
}

I realize this doesn't answer the question of why the zip files created by ZipArchive are getting messed up, but hopefully it provides another way to get things working for you.

Jonathan Head
  • 428
  • 3
  • 7
0

What browsers have you tried it with? I've had experiences before where a compressed file wouldn't uncompress properly when downloaded via a certain browser (Chrome, in this case). I tried downloading the file in Safari and it worked just fine. I'm not sure why this is, though, but try using a different browser and see if it works.

MattS
  • 717
  • 2
  • 7
  • 22
  • I tried Safari and it still doesn't unzip for me. However, this does make me wonder whether the server could be sending the wrong MIME type. – JWWalker Jun 04 '12 at 23:37
  • Yeah I tried Safari too, and same problem. I think I have the correct MIME type, I have: header('Content-Type: application/zip'). – EddyTheB Jun 07 '12 at 15:44