Skip Menu |
 

This queue is for tickets about the IO-Compress CPAN distribution.

Report information
The Basics
Id: 72548
Status: resolved
Priority: 0/
Queue: IO-Compress

People
Owner: Nobody in particular
Requestors: david [...] dtodd.net
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 2.043



Subject: Errors processing central directory in IO::Uncompress::Unzip
Date: Sat, 19 Nov 2011 00:13:28 -0600
To: bug-IO-Compress [...] rt.cpan.org
From: David Todd <david [...] dtodd.net>
Download (untitled) / with headers
text/plain 2.8k
My apologies for not having an account into the rt.cpan.org website to post this directly, I've given this issue a lot of hours of attention today and would hope that anyone else can do the same. when extracting members from a zip using ::Unzip via the 'walking a zip' method, either with the zip stored in a scalar, or allowing the module to open the file directly the module will not extract the last member encountered in the zip only in these conditions: * The last member in the archive must be compressMethod == 0 (stored) * The last member must have a total size greater than the BlockSize (if specified) or 4096 (the default) a smaller member will extract normally. * There must be at least two members in the zip. I've tested up to five, if the last member meets the above requirements it will not extract. Here's a post of my test code, it's not pretty -- http://pastie.org/2886941 using the zip utility on an example archive I have built on my machine, the contents listing is thus: Archive: new.zip Length Method Size Cmpr Date Time CRC-32 Name -------- ------ ------- ---- ---------- ----- -------- ---- 73761964 Stored 73761964 0% 10-27-2011 04:17 8410422c city.dir 62593 Stored 62593 0% 11-18-2011 23:37 55f7d5d6 new.log -------- ------- --- ------- 73824557 73824557 0% 2 files my perl script generates this output: Offs 73761964 Dec city.dir : 73761964 of 73761964 bytes done HeaderLen: (66) Bytes Left: 4 Offs 4096 Dec new.log : -1 of 62593 bytes done HeaderLen: (65) Bytes Left: 4 Wasn't able to unpack the entire stored file... Unzip Error: The trailingData() looks like it is 4 bytes long. Offs 58674 Dec new.log : 58674 of 62593 bytes done HeaderLen: (65) Bytes Left: 0 Wasn't able to unpack the entire stored file... Unzip Error: The trailingData() looks like it is 0 bytes long. This is in strict => 0; if I set strict => 1 the $UnzipError will be populated with "Trailer Error: CRC mismatch" Reproduction is very simple -- create a zip archive with two members in store mode. Alternatively, one member can be renamed and appended with '.Z' if the zip application you use will automatically store that file (mine will). so long as the last member in the list is both larger than the BlockSize and stored, not deflated, a $u->read(); operation will fail with -1 upon encountering the last file. My immediate workaround has been to set BlockSize to be larger than the last member in the archive (if stored) however, since BlockSize determines memory utilization, this limits the practical usefulness depending on the number of members in the archive or the max size of the last member. I haven't been able to devote much time to debugging to figure out why, but I have a feeling the BlockSize trigger is a big clue to something. Thanks, David
Download (untitled) / with headers
text/plain 421b
Hi David, many thanks for the detailed bug report. Don't wory about not having an RT account - as long as the report gets to me I don't mind how. I've reproduced the problem you are experiencing - luckily (for me) it is an easy one to fix. I'm just finished testing the fix - a new version of IO-Compress (2.043) is just being uploaded to CPAN. If you have any more problems with this module, please contact me. Paul


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.