Bug #90120 for IO-Compress: IO::Uncompress::Unzip sets eof when zip file has multiple folders

Thu Nov 07 10:57:41 2013 Jason.Hardies [...] wolterskluwer.com - Ticket created

Subject:	IO::Uncompress::Unzip sets eof when zip file has multiple folders
Date:	Thu, 7 Nov 2013 15:57:22 +0000
To:	"bug-IO-Compress [...] rt.cpan.org" <bug-IO-Compress [...] rt.cpan.org>
From:	"Hardies, Jason" <Jason.Hardies [...] wolterskluwer.com>

I've encountered a bug that was introduced sometime between IO::Compress versions 2.030 and 2.061. When reading a zip file whose content is inside 2 or more layers of folders, IO::Uncompress::Unzip immediately sets the eof flag. I've attached an example file that causes this issue. The code below will reproduce the issue if the content of the file is in $buffer. my $z = new IO::Uncompress::Unzip \$buffer; print "EOF:".$z->eof()."\n"; With version 2.030, when reading the zip file, the first item read was a folder item where $z->getHeaderInfo()->{Name} would be set to something like "Folder\Sub1\". I think IO::Uncompress::Unzip is not seeing the status it wants when it checks the first item of the zip file. It reads the zip file properly if I comment out the contents of the if ($status) block in sub _create in IO::Uncompress::Base. if ($status) { # Need to try uncompressing to catch the case # where the compressed file uncompresses to an # empty string - so eof is set immediately. my $out_buffer = ''; $status = $obj->read(\$out_buffer); if ($status < 0) { *$obj->{ReadStatus} = [ $status, $obj->error(), $obj->errorNo() ]; } $obj->ungetc($out_buffer) if length $out_buffer; } else { Thanks, Jason Hardies

Download Folder.zip
application/x-zip-compressed 14.2k

Message body not shown because it is not plain text.

Sat Nov 09 08:55:21 2013 pmqs [...] cpan.org - Correspondence added

Hey Jason, my intention with IO::Uncompress::Unzip (and the othe compression/uncompression modules) is to provide a filehandle interface that matches what the standard Perl file handling functions do. For eof in particular, the code below shows what it does when you open a zero length file. open F, "</dev/null" or die ; my $eof = eof F; print "EOF $eof\n"; The code prints "EOF 1". So eof is set without having attempted to read from the filehandle. Here is what your zip file contains. $ unzip -l /tmp/Folder.zip Archive: /tmp/Folder.zip Length Date Time Name --------- ---------- ----- ---- 0 2013-11-07 09:22 Folder/Sub1/ 12495 2011-05-04 12:27 Folder/Sub1/Doc1.docx 6426 2011-08-02 12:47 Folder/Sub1/Untitled - Notepad.pdf --------- ------- 18921 3 files The first member of the Zip file, Folder/Sub1/, is a directory entry that has no payload data associated with it. This is the equivalent of a zero length file, so setting eof immediately in my module matches the behaviour of the standard Perl eof function. This bug was reported in https://rt.cpan.org/Ticket/Display.html?id=67554 in and fixed in version 2.034 of this module. If this behaviour is causing problems with your code, or I've misread what I think your issue is, please get back to me. Paul

Sat Nov 09 08:55:22 2013 The RT System itself - Status changed from 'new' to 'open'

Tue Nov 12 11:18:14 2013 Jason.Hardies [...] wolterskluwer.com - Correspondence added

Subject:	RE: [rt.cpan.org #90120] IO::Uncompress::Unzip sets eof when zip file has multiple folders
Date:	Tue, 12 Nov 2013 16:17:45 +0000
To:	"bug-IO-Compress [...] rt.cpan.org" <bug-IO-Compress [...] rt.cpan.org>
From:	"Hardies, Jason" <Jason.Hardies [...] wolterskluwer.com>

Ah, I think I just misunderstood the use of eof. It indicates the end of the current stream, not the end of the zip file. Thanks, Jason Show quoted text

-----Original Message----- From: Paul Marquess via RT [mailto:bug-IO-Compress@rt.cpan.org] Sent: Saturday, November 09, 2013 7:55 AM To: Hardies, Jason Subject: [rt.cpan.org #90120] IO::Uncompress::Unzip sets eof when zip file has multiple folders <URL: https://rt.cpan.org/Ticket/Display.html?id=90120 > Hey Jason, my intention with IO::Uncompress::Unzip (and the othe compression/uncompression modules) is to provide a filehandle interface that matches what the standard Perl file handling functions do. For eof in particular, the code below shows what it does when you open a zero length file. open F, "</dev/null" or die ; my $eof = eof F; print "EOF $eof\n"; The code prints "EOF 1". So eof is set without having attempted to read from the filehandle. Here is what your zip file contains. $ unzip -l /tmp/Folder.zip Archive: /tmp/Folder.zip Length Date Time Name --------- ---------- ----- ---- 0 2013-11-07 09:22 Folder/Sub1/ 12495 2011-05-04 12:27 Folder/Sub1/Doc1.docx 6426 2011-08-02 12:47 Folder/Sub1/Untitled - Notepad.pdf --------- ------- 18921 3 files The first member of the Zip file, Folder/Sub1/, is a directory entry that has no payload data associated with it. This is the equivalent of a zero length file, so setting eof immediately in my module matches the behaviour of the standard Perl eof function. This bug was reported in https://rt.cpan.org/Ticket/Display.html?id=67554 in and fixed in version 2.034 of this module. If this behaviour is causing problems with your code, or I've misread what I think your issue is, please get back to me. Paul

Sun Dec 15 14:25:26 2013 pmqs [...] cpan.org - Status changed from 'open' to 'resolved'