Zip file directory creation problem

[Mark F]

While extracting zip files I've come accross a strange error. I use the
code below to check if the directory exists and create it if necessary. The
problem is that it works for most zip files but I have a few zip files that
do not properly extract using this code.

What seems to be happening is the variable e is referencing a ZipEntry that
is a directory but it is not being recognized as a directory in the code.

So I get the following debug info printed:
Extracting AuthorizedDBProject.zip to: D:\zips\AuthorizedDBProject
D:\zips\AuthorizedDBProject\AuthorizedDBProject\AuthorizedDBProject.jpx (The
system cannot find the path specified)

The ZipEntry is: AuthorizedDBProject/AuthorizedDBProject.jpx but
AuthorizedDBProject is not being created before extracting
AuthorizedDBProject.jpx.

Any pointers, suggestions will be appreciated.


Code:
________________

//location - a base directory to extract all the files

try {
in = new BufferedInputStream ( new FileInputStream ( _file ) );
zin = new ZipInputStream ( in );
ZipEntry e;
while ( ( e = zin.getNextEntry () ) != null ) {
File entryPath = new File ( location.toString () + File.separator +
e.getName ());

if ( e.isDirectory () ) {
if ( !entryPath.exists()) {
if(entryPath.mkdir()){
System.out.println (entryPath + " does not exist,
creating..." );
}else{
System.out.println (entryPath + " does not exist and there was
a problem creating it!!!" );
}
}
continue;
}

System.out.println(e.getName() + " is NOT a directory");
System.out.println ( "Extracting: " + e.getName() + " to " +
entryPath );
out = new FileOutputStream ( entryPath );
byte[] b = new byte[ 512 ];
int len = 0;
while ( ( len = zin.read ( b ) ) != -1 ) {
out.write ( b , 0 , len );
}
out.close ();

}
extracted = true;
} catch ( FileNotFoundException ex ) {
System.out.println ( ex.getMessage () );
} catch ( IOException io ) {
System.out.println ( io.getMessage () );
} finally {
if ( out != null ) {
try {
out.close ();
} catch ( IOException ex1 ) {
System.out.println ( ex1.getMessage () );
}
}
...

 

[Andrew Thompson]

While extracting zip files I've come accross a strange error. I use the
code below to check if the directory exists and create it if necessary. The
problem is that it works for most zip files but I have a few zip files that
do not properly extract using this code.

It seems from a cursory inspection of your
code (cough)snippet(cough..) that you are
iterating the entries. There are different
ways to retreive Zip contents, but I'll leave
it to Chris to explain..
<http://google.com/groups?group=comp.lang.java.*&q=uppal+zip>

[ Top link, most likely.. ]

HHH ;-)

 

[Chris Uppal]

While extracting zip files I've come accross a strange error. I use the
code below to check if the directory exists and create it if necessary.
The problem is that it works for most zip files but I have a few zip
files that do not properly extract using this code.

[Thanks to Andrew for the google link, btw, but I don't think I've emphasised
the ordering point before, so...]

Given the case of a Zipfile created to hold a single "real" file:

dir/file.txt

There are at least three different ways that the zipfile's contents can be
arranged.

V1) The zipfile /only/ contains the file, and has no explicit mention of the
directory (it is up to the application to read the filenames and deduce any
necessary directories); so the entire contents of the zipfile is a single
record for:
dir/file.txt

V2) The zipfile contains a record for the directory followed by a record for
the file:
dir/
dir/file.txt

V3) The zipfile contains a record for the file followed by a record for the
directory:
dir/file.txt
dir/

V1 is the generally recommended form to use. Certainly you /must/ be able to
handle (V1) unless you have complete control of the creation of the zipfile too
(in which case you can do whatever you want, the "filenames" are only strings,
so you can interpret them as meaning anything at all).

V3 may look odd, but there are no constraints at all on the order of elements
in
a Zip file. (And even if there were, the order is under the control of the
code that created it, so your reader code could not safely assume that it had
obeyed those constraints.)

I think your code assumes (V2), and -- as you have discovered -- it shouldn't
;-)

-- chris

 

[Mark F]

Thank you Chris,

That was exactly the kind of information I was looking for and it was
explained very well.

-Mark

While extracting zip files I've come accross a strange error. I use the
code below to check if the directory exists and create it if necessary.
The problem is that it works for most zip files but I have a few zip
files that do not properly extract using this code.

[Thanks to Andrew for the google link, btw, but I don't think I've emphasised
the ordering point before, so...]

Given the case of a Zipfile created to hold a single "real" file:

dir/file.txt

There are at least three different ways that the zipfile's contents can be
arranged.

V1) The zipfile /only/ contains the file, and has no explicit mention of the
directory (it is up to the application to read the filenames and deduce any
necessary directories); so the entire contents of the zipfile is a single
record for:
dir/file.txt

V2) The zipfile contains a record for the directory followed by a record for
the file:
dir/
dir/file.txt

V3) The zipfile contains a record for the file followed by a record for the
directory:
dir/file.txt
dir/

V1 is the generally recommended form to use. Certainly you /must/ be able to
handle (V1) unless you have complete control of the creation of the zipfile too
(in which case you can do whatever you want, the "filenames" are only strings,
so you can interpret them as meaning anything at all).

V3 may look odd, but there are no constraints at all on the order of elements
in
a Zip file. (And even if there were, the order is under the control of the
code that created it, so your reader code could not safely assume that it had
obeyed those constraints.)

I think your code assumes (V2), and -- as you have discovered -- it shouldn't
;-)

-- chris

 

[Mark F]

While extracting zip files I've come accross a strange error. I use the
code below to check if the directory exists and create it if necessary.
The problem is that it works for most zip files but I have a few zip
files that do not properly extract using this code.

[Thanks to Andrew for the google link, btw, but I don't think I've emphasised
the ordering point before, so...]

Given the case of a Zipfile created to hold a single "real" file:

dir/file.txt

There are at least three different ways that the zipfile's contents can be
arranged.

V1) The zipfile /only/ contains the file, and has no explicit mention of the
directory (it is up to the application to read the filenames and deduce any
necessary directories); so the entire contents of the zipfile is a single
record for:
dir/file.txt

V2) The zipfile contains a record for the directory followed by a record for
the file:
dir/
dir/file.txt

V3) The zipfile contains a record for the file followed by a record for the
directory:
dir/file.txt
dir/

V1 is the generally recommended form to use. Certainly you /must/ be

able

to
handle (V1) unless you have complete control of the creation of the zipfile too
(in which case you can do whatever you want, the "filenames" are only strings,
so you can interpret them as meaning anything at all).

V3 may look odd, but there are no constraints at all on the order of elements
in
a Zip file. (And even if there were, the order is under the control of the
code that created it, so your reader code could not safely assume that

it

had
obeyed those constraints.)

I think your code assumes (V2), and -- as you have discovered -- it shouldn't
;-)

-- chris

-Oops

Sorry about the top posting.

-Mark

 

[Andrew Thompson]

On Tue, 27 Jul 2004 07:51:09 -0500, Mark F wrote:

Hi Mark, glad you got your solution
( knew Chris was lurking ;-).

Since you demonstrated the desire and inclination
to be a full on netizen* in your last posts I will
offer you the tip that, while your intentions were
right, there is an even *better* way to post replies..

* net citizen - AFAIU

The idea is, quote as little of a former post as
you need to give a context, then put the reply
immediately beneath.

Technically it is referred to as neither
'top-posting' nor 'bottom-posting', but
'inline-posting', and almost *presumes*
heavy trimming. The trimming really helps
the folks on slow connections particularly.

 

[Mark F]

The idea is, quote as little of a former post as

you need to give a context, then put the reply
immediately beneath.

This is exactly my favorite way to post a reply. However I have been
accused of "mangling" the previous post and "destroying the thread
information" when I have done this in the past. It seems to be one of those
no-win situations but I think I will stick with it anyway. Everyone has a
way they like it and if you didn't do it their way then it is wrong. I've
even had some people (OE users) who prefer that I top post.

thanks,
-Mark

 

[Roedy Green]

This is exactly my favorite way to post a reply. However I have been
accused of "mangling" the previous post and "destroying the thread
information" when I have done this in the past.

I find it irritating when people quote something irrelevant to their
reply. It just wastes time scrolling over it. It just confuses what
the post is really about, specially when you have to scroll scroll
scroll only to get finally to some lame wisecrack.

I think we should move toward quoting no more than we would in
ordinary speech. In newsgroups, we have the advantage of being able
to review what was said if we forgot.

Bulk quoting was appropriate in times when there were no newsreaders
to track threads.