Re: ZipFile bug

[Mark Wielaard]

Hi,

On Tue, 2003-12-09 at 20:20, Archie Cobbs wrote:
> The web site still seems to be down, so here is a bug report FWIW...
> 
>     public class xx {
>       public static void main(String[] args) throws Exception {
>           ZipFile f = new ZipFile("/dev/null");
>       }
>     }
> 
> This program generates a ZipException on JDK, but Classpath
> does not try to verify the file at all so doesn't throw any
> exception... even if you then try to read the file's entries.
> 
> Instead what happens is you get null back from ZipFile.entries()
> which is not according to spec. The ZipFile constructor should try
> to do some minimal verification of the files's signature, etc.

Thanks for the report. Still don't know when savannah will be up again.
During a large part of the day all the other gnu servers were also down.
They are up again now. But I don't know why.

> I think a simple fix would be to try to read the directory
> (which you are most likely going to have to do later anyway)
> in the constructor(s).

I believe that was what the code did in the past. But some programs open
lots of zip/jar files while starting up and we didn't want to read the
whole zip directory and construct all those ZipEntries during opening
when the entries might not be needed much later (or at all).

A good fix would be to only put the check that the file starts with
LOCSIG (PK\003\004) in the constructor, but not explicitly try to read
all entries.

Also nice would be to make the reading/construction of the whole
directory lazy and stop when the entry that was needed is found. But
that is much more work since you then have to remember where in the
directory you were when another entry is needed that is not yet in the
map but you haven't read the complete directory yet.

Cheers,

Mark

signature.asc
Description: This is a digitally signed message part