Zip file directory creation problem

java-programmer, Zip file directory creation problem 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 () );
}
}
...

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

java-programmer >> Zip file directory creation problem On Mon, 26 Jul 2004 12:37:30 -0500, Mark F wrote:

> 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 ;-)

--
Andrew Thompson
http://www.PhySci.org/ Open-source software suite
http://www.PhySci.org/codes/ Web & IT Help
http://www.1point1C.org/ Science & Technology

java-programmer >> Zip file directory creation problem Mark F wrote:

> 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

java-programmer >> Zip file directory creation problem Thank you Chris,

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

-Mark

"Chris Uppal" <email***@***.com> wrote in message
news:email***@***.com...
> Mark F wrote:
>
> > 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
>
>
>

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

java-programmer >> Zip file directory creation problem > "Chris Uppal" <email***@***.com> wrote in message
> news:email***@***.com...
> > Mark F wrote:
> >
> > > 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

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

java-programmer >> Zip file directory creation problem 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.

--
Andrew Thompson
http://www.PhySci.org/ Open-source software suite
http://www.PhySci.org/codes/ Web & IT Help
http://www.1point1C.org/ Science & Technology

java-programmer >> Zip file directory creation problem > 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

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

java-programmer >> Zip file directory creation problem On Wed, 28 Jul 2004 11:13:38 -0500, "Mark F"
<email***@***.com> wrote or quoted :

>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.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.