Bug 35000 - <unzip> does not fail on archives with broken directory index
Summary: <unzip> does not fail on archives with broken directory index
Status: RESOLVED FIXED
Alias: None
Product: Ant
Classification: Unclassified
Component: Core tasks (show other bugs)
Version: 1.6.1
Hardware: Macintosh Mac OS X 10.3
: P2 normal (vote)
Target Milestone: 1.8.0
Assignee: Ant Notifications List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-05-21 12:19 UTC by Thomas Aglassinger
Modified: 2008-07-18 03:14 UTC (History)
1 user (show)



Attachments
ZIP archive with broken directory index (326 bytes, application/octet-stream)
2005-05-21 12:26 UTC, Thomas Aglassinger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Aglassinger 2005-05-21 12:19:11 UTC
I've created a ZIP archive to reproduce Sun bug 4615343 (ZipFile.entries()
throws java.lang.InternalError). InfoZip's unzip 5.50 also agrees that the
archive is broken:

---------
$ unzip -l broken-index.zip 
Archive:  broken-index.zip
error [broken-index.zip]:  NULL central directory offset
  (attempting to process anyway)
  Length     Date   Time    Name
 --------    ----   ----    ----
     4096  01-01-80 00:00   1.txt
     4096  01-01-80 00:00   2.txt
 --------                   -------
     8192                   2 files
---------

However, if I try to unzip it using the following build.xml, ant neither detects
an error nor does it extract anything:

---------
<?xml version="1.0"?>
<project name="unzip-broken-index" default="build" basedir=".">
    <target name="build">
        <unzip src="broken-index.zip" dest="."/>
    </target>
</project>
---------

Here's the console output:

---------
$ ant build
Buildfile: build.xml

build:
    [unzip] Expanding: .../broken-index.zip into ...

BUILD SUCCESSFUL
Total time: 0 seconds
---------

My expectation would have been that <unzip> fails with an error message like
"ZIP file directory index must be fixed" or something similar.

I didn't see any way to attach the test archive to this bug. It is really small,
so I'll just insert a uuencoded copy of it:

begin 644 broken-index.zip
M4$L#!!0`"``(````(0`````````````````%````,2YT>'3MP4$.0!$,0$%K
MI^C5I/RDBZKP+=S>/>3-U.U^I+:ET\9OT24^*:+AICD!`````(`77%!+!PB'
MK#S<,@`````0``!02P,$%``(``@````A``````````````````4````R+G1X
M=.W!00Y`$0Q`06NGZ-6D_*2+JO`MW-X]Y,W4[7ZDMJ73QF_1)3XIHN&F.0$`
M````@!=<4$L'"(>L/-PR`````!```%!+`0(4`!0`"``(````(0"'K#S<,@``
M```0```%```````````````````````Q+G1X=%!+`0(4`!0`"``(````(0"'
MK#S<,@`````0```%`````````````````&4````R+G1X=%!+!08``````@`"
+`&8`````````````
`
end
Comment 1 Thomas Aglassinger 2005-05-21 12:26:46 UTC
Created attachment 15104 [details]
ZIP archive with broken directory index
Comment 2 Thomas Aglassinger 2005-05-21 13:01:18 UTC
The problem seems to be that ZipFile.populateFromCentralDirectory() ignores the
case that the directory is empty. Here's a suggested fix for the current CVS
revision 1.19:

    private void populateFromCentralDirectory()
        throws IOException {
        positionAtCentralDirectory();

        byte[] cfh = new byte[CFH_LEN];

        byte[] signatureBytes = new byte[4];
        archive.readFully(signatureBytes);
        long sig = ZipLong.getValue(signatureBytes);
        final long cfhSig = ZipLong.getValue(ZipOutputStream.CFH_SIG);
>       if (sig != cfhSig) {
>           throw new ZipException("cannot find ZIP directory index");
>       }
        while (sig == cfhSig) {
            ...
Comment 3 Stefan Bodewig 2008-07-17 06:14:50 UTC
will fail starting with svn revision 677575
Comment 4 Stefan Bodewig 2008-07-17 07:24:02 UTC
hmm, the same change would prevent Ant from dealing with empty archives.

For now I've added a failOnEmptyArchive attribute to unzip an friends.

svn revision 677592
Comment 5 Stefan Bodewig 2008-07-18 03:14:28 UTC
separated this sort of broken archive from the general "central directory is empty because the archive is empty" case completely.

unzipping the attachment will fail, unzipping of empty archives will not, unless the task is explicitly asked to do that.

svn revision 677870