Zip file directory creation problem

Discussion in 'Java' started by Mark F, Jul 26, 2004.

  1. Mark F

    Mark F Guest

    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! =-----
     
    Mark F, Jul 26, 2004
    #1
    1. Advertising

  2. 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
     
    Andrew Thompson, Jul 26, 2004
    #2
    1. Advertising

  3. Mark F

    Chris Uppal Guest

    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
     
    Chris Uppal, Jul 27, 2004
    #3
  4. Mark F

    Mark F Guest

    Thank you Chris,

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

    -Mark

    "Chris Uppal" <-THIS.org> wrote in message
    news:...
    > 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! =-----
     
    Mark F, Jul 27, 2004
    #4
  5. Mark F

    Mark F Guest

    > "Chris Uppal" <-THIS.org> wrote in message
    > news:...
    > > 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! =-----
     
    Mark F, Jul 27, 2004
    #5
  6. 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
     
    Andrew Thompson, Jul 27, 2004
    #6
  7. Mark F

    Mark F Guest

    > 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! =-----
     
    Mark F, Jul 28, 2004
    #7
  8. Mark F

    Roedy Green Guest

    On Wed, 28 Jul 2004 11:13:38 -0500, "Mark F"
    <> 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.
     
    Roedy Green, Jul 28, 2004
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    0
    Views:
    1,782
  2. HARI OM
    Replies:
    0
    Views:
    17,479
    HARI OM
    May 3, 2005
  3. abcd
    Replies:
    7
    Views:
    537
    Edward Elliott
    May 1, 2006
  4. majj81
    Replies:
    0
    Views:
    347
    majj81
    May 31, 2006
  5. Chris Lambacher

    Re: Add file to zip, or replace file in zip

    Chris Lambacher, Jun 1, 2006, in forum: Python
    Replies:
    0
    Views:
    637
    Chris Lambacher
    Jun 1, 2006
Loading...

Share This Page