views:

76

answers:

1

I'm trying to put together a zip streaming solution through the use of Unix's zip command and PHP's passthru function, but I've hit a snag.

The script looks something like this:

<?php
header("Content-Type: application/octet-stream");
header("Content-Disposition: attachement; filename=myfile.zip");
passthru("zip -r -0 - /stuff/to/zip/");
exit();
?>

The zip command works OK and the output is received by the browser and saved as a zip file. The zip can then be extracted fine on Windows and Unix, but on Mac OS X the build in extractor (BOMArchiveHelper) can't extract the file. Using other applications on OS X works fine though.

The error given by BOMArchiveHelper is the same it gives if a zip is password protected (not handled by the application). I used some kind of zip analyzer program and it indicated that some of the files in the zip archive were flagged as password protected. Like I said though, no other extraction application pays attention to that apparently.

When examening the zip closer I found that the one generated by the PHP files is a few bytes larger than one generated directly by the zip command on the server. It seems that the stream process with passthru adds something to the file that probably causes the problems with BOMArchiveHelper.

To test this, I used passthru to stream a zip I had already created on the server: passthru("cat stuff.zip") That worked fine with BOMArchiveHelper.

So the problem seems to lie somewhere in the process where the passthru function takes the binary data generated on the fly by the zip command and passes that to the browser.

I've tried to eliminate all the sources where the extra bytes could be generated (setting zip command to quiet and so on), but the added data still remains. A binary diff of the streamed zip and a pre generated zip shows that the extra data is scattered all over the zip, not just in the end or the beginning.

Anyone have a clue, or seen this problem before and decided it's impossible to solve?

NB: Since someone else has already encountered and very well described this issue before me without any answer I just copied/paste his message here and made sure that all his tests did effectively fail and neither any of mine passed ...

Apparently the only way to get this to work would be to ask people to use either unzip or suffitexpander ...

A: 

If you are using nginx then take a look at http://wiki.nginx.org/NginxNgxZip

Steffen
Very nice, I really like this. I am currently using Apache2 but will definitely try this out. I also need to make sure that it won't store the zip on the disk because I need something that streams it right away by adding the file to the zip dynamically without storing the whole file on the server like many other zipOnTheFlyScripts are doing. I'll let you know how things go on! Thx
Julien P.