|
Posted by Alan Stewart on November 8, 2005, 5:59 pm
Please log in for more thread options
On Tue, 08 Nov 2005 21:21:52 GMT, graham@nospam.steelworks.org.uk
(Graham) wrote:
>The sample program does exhibit the problem on my system. I am using
>Perl build 805 rather than 810, but I downloaded Archive::Zip module
>v1.16, because the older version provided with build 805 includes a
>separate Tree module. If I zip up a sample tree using the script
>below, the freeware infozip utility shows no problem with the
>contents, but if I open the Compressed folder in Windows Explorer it
>shows zero length files alongside the folders, with the same name as
>the folders, and extraction fails. If I create the compressed folder
>using the Windows built-in compressed folder functionality, it creates
>a similar zip but without the zero length files.
>
>On Mon, 7 Nov 2005 10:57:30 +1100, "Sisyphus"
>
>>Couldn't reproduce the problem. This worked fine for me (AS perl build 810):
>>
>>use warnings;
>>use Archive::Zip;
>>$zip = Archive::Zip->new();
>>$zip->addTree( '.', '');
>>$zip->writeToFileNamed("test.zip");
>>
By default, addTree and infozip add entries for each file and and for
each directory to the zip file, while pkzip and Windows do not add
directory entries.
Perhaps Windows is having a problem with the directory entries and
trying to treat them as zero length files.
Can Windows handle a zip created by infozip with just -r ?
To prevent infozip from making dir entries, use -D:
zip -r -D some.zip my_dir/
To prevent addTree from doing it, use a filter:
$zip->addTree( $root, $dest, sub { -f } )
This came up in a PAR discussion, since PAR also didn't handle dir
entries well.
Alan Stewart
| 
XML Sitemap