- Problem:

    The class java.util.ZipFile cannot be used to write or modify
    ZIP files. This functionality is needed by the JAR tool in
    order to support updating existing JAR files. Currently,
    the tool can only be used to read or create JAR files.
    These enhancements have also been frequently requested from
    outside users.

- Solution:

    Solution is to add additional methods to java.util.ZipFile
    to support writing and modifying ZIP files.


- Proposed API change:

    Have ZipFile implement java.util.Map, and add the following
    new methods:

    /**
     * Opens a ZIP file for reading, overwriting or modifying
     * given the specified file name and access mode.
     * <p>
     * The mode argument must be <code>"r"<code>, <code>"w"<code> 
     * or <code>"rw"</code>, indicating to open the file for input, 
     * to overwrite or to modify.
     *
     */
    public ZipFile(String name, String mode) throws IOException {
    }


    /**
     * Opens a ZIP file for reading, overwriting or modifying
     * given the specified file name.
     * <p>
     * The mode argument must be <code>"r"<code>, <code>"w"<code> 
     * or <code>"rw"</code>, indicating to open the file for input, 
     * to overwrite or to modify.
     * 
     */
    public ZipFile(File file, String mode) throws ZipException, IOException {
    }

    /**
     * Returns an output stream for writing the contents of the specified
     * ZIP file entry.
     *
     */
    public OutputStream getOutputStream(ZipEntry ze) throws IOException {
    }	

    /**
     * Adds the specified zip entry to the end of the zip file.
     * If the zip file already contains this entry, an exception
     * will be thrown.
     */
    public void add(ZipEntry ze) {
    }

    /**
     * Adds the specified zip entry to the current zip file at the
     * specified index. If the zip file already contains this
     * entry, an exception will be thrown.
     */
    public void add(int index, ZipEntry ze) {
    }

    /**
     * Returns the position of the zip entry for the specified
     * file name in the current zip file.
     */
    public int indexOf(String name) {
    }




FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

FULL OPERATING SYSTEM VERSION :
SunOS ruyaksun 5.8 Generic_108528-14 sun4u sparc SUNW,Ultra-5_10

ADDITIONAL OPERATING SYSTEMS :
Windows



A DESCRIPTION OF THE PROBLEM :
There should be an api for inserting a file (or other entry)
into an already existing archive (zip or jar file) much like
the jar utility provides.

For example:

jar -uf <jar-file> <input-file-name>

This inserts the <input-file-name> into the <jar-file>
without having to explode the already existing jar file in a
temporary location, copying over the file to insert, and
then jaring this up in a new jar file.

The ZipFile api does include a putNextEntry(ZipEntry entry)
 method, but this only inserts an entry into a new ZipFile
obj. through a ZipOutputStream (or JarOutPutStream) NOT an
existing archive.  It would be helpful to have this feature
so that one can programmatically insert a new entry into an
existing archive without having to create a new one.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Execute code below using an existing zip or jar file with
entries.

EXPECTED VERSUS ACTUAL BEHAVIOR :
Expected helloworld.war when issuing a jar -tvf:

 0 Thu Jun 06 13:32:30 PDT 2002 META-INF/
    68 Thu Jun 06 13:32:30 PDT 2002 META-INF/MANIFEST.MF
   352 Tue Apr 30 21:28:38 PDT 2002 GreeterView.jsp
     0 Thu Jun 06 13:31:56 PDT 2002 WEB-INF/
     0 Tue Apr 30 21:28:38 PDT 2002 WEB-INF/classes/
     0 Tue Apr 30 21:28:38 PDT 2002 WEB-INF/classes/samples/
     0 Tue Apr 30 21:28:38 PDT 2002
WEB-INF/classes/samples/helloworld/
     0 Tue Apr 30 21:28:38 PDT 2002
WEB-INF/classes/samples/helloworld/servlet/
  3146 Tue Apr 30 21:28:38 PDT 2002
WEB-INF/classes/samples/helloworld/servlet/GreeterServlet.class
  1046 Tue Apr 30 21:28:38 PDT 2002 WEB-INF/web.xml
   462 Thu Jun 06 13:31:52 PDT 2002 WEB-INF/sun-web.xml
   934 Tue Apr 30 21:28:38 PDT 2002 index.html
   934 Tue Apr 30 21:28:38 PDT 2002 name.xml

Actual helloworld.war after performing a jar -tvf:

76 Thu Jun 20 16:39:32 PDT 2002 name.xml


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
Here is sample code that I wrote to attempt to insert an entry into an existing
archive.  The result was that a new archive is created with that new entry only.
None of the entries from the existing archive were there.

/**
 * Inserts a entry into an existing archive file.
 *
 * @param java.lang.String File name of file to insert into archive.
 * @param java.util.zip.ZipFile Archive into which file in inserted.
 */
private static void insertFileIntoArchive(String fileName, java.util.zip.ZipFile
zipFile){
        java.util.Date today;
	long systime;
        today = new java.util.Date();
        systime = today.getTime();
        
        try{
            //reading new File
            File newFile = new File(fileName);
            System.out.println("Reading new File: " + newFile.getName());
            FileInputStream fileStream = new FileInputStream(newFile);
            byte[] fileData = new byte[new Long(newFile.length()).intValue()];
            fileStream.read(fileData);
            fileStream.close();
               
            //outputStream stuff
            FileOutputStream output = new FileOutputStream(zipFile.getName());
            JarOutputStream jarStream = new JarOutputStream(output);
            jarStream.setMethod(JarOutputStream.DEFLATED);
            
            //zipEntry
            ZipEntry zipentry = new ZipEntry(fileName);
            zipentry.setMethod(zipentry.DEFLATED);
            zipentry.setSize(fileData.length);
            zipentry.setTime(systime);
            CRC32 crc321 = new CRC32();
            crc321.update(fileData);
            zipentry.setCrc(crc321.getValue());
            
            //adding to the new jarOutputStream
            jarStream.putNextEntry(zipentry);
            jarStream.write(fileData);
            jarStream.flush();
            jarStream.flush();
            jarStream.closeEntry();
            
            //finished
            jarStream.finish();
            jarStream.close();
            
        }catch(java.io.FileNotFoundException fnfe){
            System.out.println("Exception: " + fnfe.getMessage());
            fnfe.printStackTrace();
        }catch( IOException io){
            System.out.println("Exception: " + io.getMessage());
            io.printStackTrace();
        }
    
    }//end insertFileIntoArchive
---------- END SOURCE ----------
(Review ID: 153930)
======================================================================

N/A

This is certainly a reasonable request, but...
- the jar command already offers the functionality from the command line.
- the jar/zip code is already fragile enough without adding a new dimension
  to the testing matrix.
- there are easy workarounds.

One can argue that the functionality would not be used by enough users
to make it worth the maintenance cost.  Certainly other improvements
to jar/zip take precedence.
  xxxxx@xxxxx   2003-10-30
It is easy to sympathize with those who want this bug fixed.  It is perhaps easier to sympathize with those who have, inadvertently, overwritten JAR files that are already in-use by a running JVM.  Consider this sampling of bugs:
4425695, 6390352, 4826081, 4843994, 6426429, 6553958, 5086611, 5082306, 6228479, 6571563

Some of the above show that replacing a JAR resulted in a JVM crash.  Readily allowing JAR files to change by providing an API to do so could result in more such.  The situation is such that it is difficult to even provide the name of the JAR which caused the crash, or to throw an IOException instead of having the crash.  See 5086611 for details on how to crash a JVM in this way.

It would have been nice if the jar & zip APIs had allowed for mutable zip files from day one.  But at this point adding mutability to jar & zip files from Java(or rather, increasing the ease of mutating them) seems likely to introduce more hard-to-debug problems.
Posted Date : 2008-02-29 20:08:28.0

I add my vote -- this problem makes all the work sun has already put into the
zip library relatively useless for most applications.  This is also a fairly
straighforward problem to fix -- there is no obvious reason not to include this
fix by jdk 1.2 release.
Thanks

If support for modifying zip files gets added to
the zip classes, please also allow zip entries to
be deleted and also for their bytes (i.e. zipped
file contents) to be replaced.  This could be
handled by a delete then add of the new entry, but
it seems like replacing the bytes would be more
efficient and preserve the order of the zip entries.

I dont agree the the interface for ZipFile has to change 
for this problem to be resolved. By allowing the
java.io.FileOutputStream constructor to append to file is 
enough. See example:
<code>
FileOutputStream fileOut = new FileOutputStream
("MyZipFile.zip", true);
ZipOutputStream zipOut = new ZipOutputStream(fileOut);
</code>

Unfortunately, the solution presented by "pascuajf" does 
not append entries to the entry list. In the scenarie 
suggested, the bytes are appended to the file, but only the 
entries added for the last instance of the ZipOutputStream 
are now present - all previous entries (but not the 
associated bytes) by other ZipOutputStream instances.

Danny, because the length of any undated file within the
archive is not necessarily the same (since the data is
compressed) deleting and re-adding a file is the best way to
update a file in a zip archive.

Still, having the capability to update zip files (and, more
particularly, jar files) using Java would be very nice
indeed, especially if javac and javadoc were altered so as
to be able to directly read and write class files out of and
into a jar.  The best you can do right now is to extract to
a temporary directory, rebuild the code/doc, and recreate
the archive at the end...

I have implemented some of this functionality already in ZIP
Thingy, a program I've been writing to investigate this sort
of thing (among others - I used it to teach myself Swing as
well).  Unfortunately, the latest build of the program is
not stable - I've broken a few things and didn't realise it,
and it's starting to need a major clean-up.

Since the API supports the creation of archives, ZIP Thingy
allows entries to be deleted from within a ZIP file. 
However, it does this by brute force, recreating the archive
from scratch and skipping any entries that the user wants
deleted.  It also supports adding entries in the same way
(adding new entries at the end of the archive, since the
order of entries does not seem to be important in the ZIP
format).  Obviously, this is a pretty hairy way of going
about things, but without knowing the exact details of the
entry before it is added, random access of archives (ie.
random addition/deletion of entries) is impossible.  This
workaround also has the advantage of being perfectly safe,
even if it is interrupted.  I'm pretty sure WinZip does
things this way.

What I would like, and am considering developing, is a
generic archive API that does support this sort of thing.  I
don't think that the java.util.zip package is that bad and
disagree with pkirkaas' comment that it is "relatively
useless for most applications", since most apps do not need
to modify existing archives.  (Note that the Java classes
are stored in JARs now, so the ZIP/JAR API is used all the
time without modification.)  Given the choice, I would base
any eventual APIs around java.util.zip, because it's pretty
simple to use.  Implementing java.util.Map, as suggested in
this bug description, would be murder.

ZIP Thingy is available under the GPL, and you can browse
the source code on-line at
http://www.roesti.f2s.com/programming/zipthingy/ - but
enough shameless plugging from me.

Cheers,
Aaron Nielsen
roesti@f2s.com

Security. I'm guessing that you can't update a zip file for
security reasons. If the JFC included a way of writing to a
jar file, a virus would have an easy way of infecting
classes in the JFC. Without this facility it is hard for a
virus to spread since most classes are contained in Jar
files. Of course a virus could contain its own
implementation, but it's a big hurdle to get over given the
minimal skills needed to write a lot of the recent big
viruses (e.g. the love letter worm). Once a virus contains
all the code needed to edit a jar, it is going to be a
pretty large class file and hence very easy for AV progs to
spot.

Still I agree, it would be nice. There are many other JFC
classes that are immutable that I wish had modifiers. The
annoying thing is, there's every reason to have two versions
of most of the immutable classes - one that's immutable and
one that has modifiers.

It is pretty easy to work around this sort of thing by just
creating a temporary zip file, copying all the unchanged
bits across, and then bunging the new stuff on the end, so
any security concerns are pretty much moot, since you are
not gaining the ability to do anything you couldn't do
before.  The security of JAR files is instead guaranteed
with mechanisms like cryptographic signing and putting the
main files in locations that can't be written to by normal
processes (where the OS supports such measures.)  All this
RFE does is make writing ZIP/JAR updating code *much* more
convenient.

I too add my vote! I was writing a backup application in Java, 
and I needed to update the zip archive I was making in that 
process(to add the newly added files to the file system on 
disk or delete the deleted ones). But Arghhhhhhhh....When I 
looked for the solutions, I found none.

The only workaround I could imagine was to copy the current 
archive to a temp file and make changes, that is, add files, 
replace files or delete files(ahhh...skip them) while copying! 
But unfortunately it takes the same time as creating a new 
archive. So hardly any of my application users use the update 
function. I tried to rewrite the zip classes, but I am not yet 
successfull!

I think this proposal is great.  The first time I looked at
the Zip tutorial and APIs, I was shocked to find out that
those features are not there.  Yes, there are things that
can be changed/added in those suggestions, but the general
idea is valid.  Some of the added feature should be secure
access (allow to access password protection), the ability to
change that attribute.  The ability to mount it as a file
system (with some limitation).  The ability to set
compression level for performance/space trade off.  Yes, you
can go on with this, but I think just the mechanism to group
many things together provide so much benefit.  Thinking of
have my disparate XML files of my application project group
together is a great idea.

AAAAAARGLLLLL!!!

Do my eyes deceive me?

A new "evaluation" has been posted (dated 2003-10-30):

- the jar command already offers the functionality from the 
command line.

So? Maybe I need to edit jar files in my application. If the 
code has been written already, why can't it be made available 
as an API?

- the jar/zip code is already fragile enough without adding a 
new dimension to the testing matrix.

Really? Is it that bad? Obviously, with so many skeletons in 
the cupboard, it may be better not to open it! Let's wait for 
something to go seriously wrong - say getting a mention in 
the press: "Levis customers embarassed by zip problem in 
Java", "US Catering service unable to open jars in Iraq, 
undernourished troops exposed to bugs and viruses".

Hello

- there are easy workarounds.

AAAAAAAAAAAAAAAAAARRRRRRRRGGGLLLLLLLLLLLLLLLLLLLLLLL
LLL!!

There is a new "Evaluation" dated 2003-10-30. Its main points 
deserve scrutiny:

- the jar command already offers the functionality from the 
command line.

Good. So if the code exists, why can't it be made available as 
an API? 
- the jar/zip code is already fragile enough without adding a 
new dimension to the testing matrix.
Really? Is it that bad? 
Yes, I suppose that with so many skeletons in the cupboard, 
it may be better not to open the door. Let's wait for 
something really drastic to happen before we open the door! 
Say something that makes the headlines:
"Levis customers embarassed by zip problem in Java".
"US Catering Corps unable to open jars - underfed troops 
exposed to bugs and viruses"
"Betty Bossy complains that signed jars cannot be trusted"

Come on - If there's a problem, solve it before the world 
hears about it!

- there are easy workarounds.
Such as?
Going to apache.org and downloading the ant source?

Have some pride! The JDK should be the standard we all drean 
to achieve, but never can. The product of the Java dream 
team - not some fragile stuff that fumbles through the test 
procedure. 
Stand up! Shoulders back! are you a man/woman or a mouse?
Such an answer is not acceptable from a member of the 
dream team!

One can argue that the functionality would not be used by 
enough users to make it worth the maintenance cost.

Ah!? How many users have to use it? compared to 
classloaders, jeva.security intricaties, phantom references 
and reflection?
How can we, a miserable minority, make our plea heard?
What about a collection to cover the maintenance cost? 
Would that help?

Certainly other improvements to jar/zip take precedence.

Examples?

Short of copying the entire (possibly huge) input file to a new output file while makeing the (possibly tiny) change, what is the easy workaround?!  The above method is far too inefficient!

See TrueZIP https://truezip.dev.java.net for an open-source 
alternative.  It extends the 
File/FileInputStream/FileOutputStream API's to work 
transparently with zip and jar files.  So modifying a zip file is 
as easy as writing a new file in a directory.

Indeed, and it also contains some smarts for direct copying of deflated data, so a ZIP file does not need to get decompressed and compressed again when updating a single entry.

All this is totally transparent to the user (developer). He just works with files located in a ZIPped directory.

Greetings from the author. ;-)

Regards, Christian Schlichtherle

Sir, i also tried a lot but the code that i have written is only adding the new files to the list and not the old list
Request if somebody can help me with the workarounds may be the cose for creating a temp folder unzipping all old and add all new the make new zip archive and save the same in the same old loc and archive name thanX

Regards sudhir

The fact that zip.exe (from www.info-zip.org) can add/update a zip entry in a large (e.g. 30-40MB) zip file *many* times faster than jar.exe can is apalling.  There are reasons to do this sort of thing and this adds a nasty credence to the "Java is slow" argument.  This is inexcusable at this point.

I agree with this request.  I have come across a problem where appending to a zip is needed.  Writing to a temp file is going to have to be the answer at the moment but is not satasfactory.

No evaluation comment since 2003?  And that was "other improvements to jar/zip take precedence" -- so what are they?  The biggest one on the bug/RFE lists is for handling of platform filename encodings, which Ant already does (so pilfer this from there).  Even so, I can think of no more important enhancement to the zip API at this point in time.

Hopefully this new functionality will include the ability to read/access the zip central directory. It seems this would be the key enabler to many of the requested enhancements:

1. No need to read/copy/unpack the entire zip.

2. Provides access to directory to create an iterator that can iterate over the unzipped entries by indexing into the original zip file.

3. Provide access to file-level and entry-level comments that can't currently be accessed using ZipInputStream. The ZipEntry class has a getComment method but will always return NULL if ZipInputStream is being used since the entry comments are actually stored in the central directory.

4. Access to the directory allows the developer to 'cherry-pick' only the entries of interest which could then be unzipped or copied to a new archive. Again without having to copy/unzip the entire archive.

Cherry-pick reading does not help when you have a 30MB zip that you want to update 3 small entries in.  zip.exe does this very quickly.  With Java this is currently impossible.  Given the importance of the zip format to Java this seems somewhat untenable.

Now I hit this bug. This is a very much desirable feature. I need to update a zip file at runtime; that's not possible because of this bug. Please implement this request. 

I think a lot of people could use this. It would be nice if you could package an application in a single jar and read/write configuration files inside this jar. I use Preferences now, but it would be cool if I could save some stuff in the jar I am currently executing, because it would bind these settings to the application jar itself, and not to some user/machine. I guess most people propably don't have a use case for something like that, ... but i do ;)

I too dont agree with the evaluation,
if the problem is security and that you could rewrite an open jar file then if it the jar belongs to the jvm and you can write to it you are using the wrong operating system, if the jar belongs to the program that you are running then the program is trashing its own jar so "deserves" to crash. How about a check to see if the class loaders have the jar open, doesnt sound too difficult.

As for fragile code being the excuse, I dont think my customers would have a lot of confidence in my software if I said I couldnt add a requirement because the code I wrote was too fragile!

It would be nice to get this fixed, what about people using a zip for archive purposes, its not an option to copy a several hundred megabyte file to a temporary file. Also as the Open Packaging Conventions use the zip format it mean that every time a user saves his work, the zip has to be modified.

I really appreciate all the hard work that you guys at Sun do but ...
any chance that over 10 years after a bug gets submitted that it could be fixed?