A zip is not a zip - portability problem with ZipIndexer

The ZipDirectoryResource has not been creating resources for subdirectories
in a zip for me.  The files work fine, but it refuses to create
subdirectories...except for the configuration file jigadmin.zip.

I've just tracked down the source, that I believe is a problem with the way
*nix and Win treat directories.  *nix treats directories more like normal
files than Windows that considers them something different.  The result is
that the zip file from *nix has line item entries for the subdirectories, a
Windows zip file does not contain these entries.  This causes failure in
this method:
protected boolean entryExists(String name) {
 File zipfile = getZipFile();
 ZipFile zip = null;
 try {
     zip = new ZipFile(zipfile);
 } catch (Exception ex) {
     ex.printStackTrace();
     return false;
 }
...snip...
 try {
     return ((zip.getEntry(full_path) != null) ||
      (zip.getEntry(full_path+"/") != null));
 } finally {
     try { zip.close(); } catch (Exception ex) {}
 }

The Windows zip file does not have an entry and zip.getEntry() fails every
time.

I've just tried several zip programs in addition to my standard (WinZip) and
none appear to have options for adding an entry for the directory.  They are
just not considered to be files.

As a proof that this was the problem I was able to trick the zip programs
into adding a line item entry by doing a recursive add of "*."  This only
works with the wildcard and cannot be controlled, i.e. the whole tree gets
added.  Even worse, the line items do not show up in the same zip programs
that created them.  Only with the Sun jar -ft can you see that these entries
are being created.  With this hack, the ZipIndexer does it's work and the
subdirectories can be browsed.

I cannot propose any easy fix.  Things that come to mind:
1) in entryExists() check not for the entry, but if any entry uses this
directory name.  This would work, but could be time consuming walking a
large zip.
2) add a special file to the zip: directories. that contains a list of all
directory paths that will be considered valid.  Maybe this could be a fall
back in the entryExists(). If the first check fails, try this.  The downside
is that creating these files by hand would be tedious and a source of
errors.
3) just return true from entryExists() - It appears that the file is indexed
an then checked soon after.  The zip file was just walked, I'm not sure I
see the need to double check.

goodnite,
Jim Rudnicki

p.s. apologies for sending this to wrong address, address book has been
corrected

Received on Monday, 11 October 1999 00:25:56 UTC