Plexus Components

zip archiver cannot update zip files

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: plexus-archiver
  • Labels:
    None
  • Environment:
    WinXP version 2002 SP1, jdk1.5.0b64, maven2
  • Number of attachments :
    4

Description

While trying to add existing file to existing jar file (update mode), archiver throws error:

Caused by: org.codehaus.plexus.archiver.ArchiverException: Problem creating jar: Negative seek offset (and the archive is probably corrupt but I could not delete it) (and I couldn't rename the temporary file ip1185187450.tmp back)
        at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:403)
        at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchive(AbstractZipArchiver.java:229)
        at com.db.gcf.gbcrm.maven2.plugins.Utils.pack(Utils.java:150)
        ... 21 more
Caused by: java.io.IOException: Negative seek offset
        at java.io.RandomAccessFile.seek(Native Method)
        at org.codehaus.plexus.archiver.zip.ZipFile.positionAtCentralDirectory(ZipFile.java:383)
        at org.codehaus.plexus.archiver.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:254)
        at org.codehaus.plexus.archiver.zip.ZipFile.<init>(ZipFile.java:148)
        at org.codehaus.plexus.archiver.zip.ZipFile.<init>(ZipFile.java:105)
        at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.getResourcesToAdd(AbstractZipArchiver.java:419)
        at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:330)
        ... 23 more

Method I used:

/**
     * Adds file or directory to given archive
     * @param archiverManager that manages archivers
     * @param aFile file or directory to pack
     * @param aArchive archive to create or update
     * @param update identifies if archive always created or existing archive is
     * created
     * @throws MojoExecutionException if any errors with file reading or writing
     * occured
     * @throws NoSuchArchiverException if archive extention does not have
     * corresponding archiver
     */
    public static void pack(ArchiverManager archiverManager, File aFile,
            String aDestFileName, File aArchive, boolean update)
            throws NoSuchArchiverException, MojoExecutionException {
        String archiveExt = FileUtils.getExtension(aArchive.getAbsolutePath())
                .toLowerCase();
        try {
            Archiver archiver = archiverManager.getArchiver(archiveExt);
            if (archiver instanceof ZipArchiver) {
                ((ZipArchiver)archiver).setUpdateMode(update);
            }
            archiver.setDestFile(aArchive);
            archiver.addFile(aFile, aDestFileName);
            archiver.createArchive();
        } catch (ArchiverException e) {
            throw new MojoExecutionException("Error occured while packing file["
                    + aFile + "] to archive[" + aArchive + "]", e);
        } catch (IOException e) {
            throw new MojoExecutionException("Error occured while packing file["
                    + aFile + "] to archive[" + aArchive + "]", e);
        }
    }
  1. Text File
    fix_update.patch
    04/Mar/11 10:29 AM
    4 kB
    Robert Scholte
  2. Text File
    fix_update.patch
    04/Mar/11 6:01 AM
    3 kB
    Robert Scholte
  3. Text File
    PLXCOMP-8.patch
    08/Mar/11 8:39 AM
    3 kB
    Robert Scholte
  4. Text File
    Verify-PLXCOMP-8.patch
    29/Sep/08 7:54 AM
    3 kB
    Florian Fray

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Florian Fray added a comment -

Could not reproduce this issue.

I've attached a patch to the JarArchiverTest and copied some of your code in.
Maybe you could re-run your code or patch the Unit-Test and modify it in a way to proove this issue against the current version of plexus-archiver.

Show
Florian Fray added a comment - Could not reproduce this issue. I've attached a patch to the JarArchiverTest and copied some of your code in. Maybe you could re-run your code or patch the Unit-Test and modify it in a way to proove this issue against the current version of plexus-archiver.
Hide
Permalink
Michal Szalinski added a comment -

I had similar issue when using version alpha-7
after update to alpha-10 this one is gone
HOWEVER:
it seems that updating an archive doesnt work at all!
to check it change the test case so update flag is true.
After adding first file archive with it is created,
when adding another file whole archive is replaced with new one containing only new file.

I checked the AbstractZipArchiver code and in createArchive method steps are as follows (in update mode):
1. create copy of archive
2. put all resources to original archive (it always overrides archive)
3. delete tmp file (which is not needed as renamedFile.deleteOnExit() is used just after file creation)

no merging of tmp and new archive is made.

Am i doing something wrong?

Show
Michal Szalinski added a comment - I had similar issue when using version alpha-7 after update to alpha-10 this one is gone HOWEVER: it seems that updating an archive doesnt work at all! to check it change the test case so update flag is true. After adding first file archive with it is created, when adding another file whole archive is replaced with new one containing only new file. I checked the AbstractZipArchiver code and in createArchive method steps are as follows (in update mode): 1. create copy of archive 2. put all resources to original archive (it always overrides archive) 3. delete tmp file (which is not needed as renamedFile.deleteOnExit() is used just after file creation) no merging of tmp and new archive is made. Am i doing something wrong?
Hide
Permalink
Robert Scholte added a comment -

I ran into this problem too, just discovered it's already a pretty old issue.
I've attached a new testcase and the required fix.
Maybe it was caused by the assumption the following code would keep the existing ZipEntries:

zOut = new ZipOutputStream( zipFile );
Show
Robert Scholte added a comment - I ran into this problem too, just discovered it's already a pretty old issue. I've attached a new testcase and the required fix. Maybe it was caused by the assumption the following code would keep the existing ZipEntries: zOut = new ZipOutputStream( zipFile );
Hide
Permalink
Robert Scholte added a comment -

A small improvement: closing the temp-zipfile so it can be removed

Show
Robert Scholte added a comment - A small improvement: closing the temp-zipfile so it can be removed
Hide
Permalink
Robert Scholte added a comment -

Previous patch only created empty entries. This one should copy the content as well. I had to fix the PlexusIoZipFileResourceCollection too, since it didn't close the ZipFile, which made it impossible to delete the temp-file.

Show
Robert Scholte added a comment - Previous patch only created empty entries. This one should copy the content as well. I had to fix the PlexusIoZipFileResourceCollection too, since it didn't close the ZipFile , which made it impossible to delete the temp-file.
Hide
Permalink
Robert Scholte added a comment -

Part of my issue was caused by an other bug, this should be the final patch.
There's one minor issue I couldn't solve:
The temporary created file can't be deleted because the ZipFile can't be closed. A ZipEntry holds a reference to the original ZipFile, so closing it too early would break the ZipEntry. The result is a warning-message that the file couldn't be deleted. Once the jvm has finished, the file is released and can be removed.

Show
Robert Scholte added a comment - Part of my issue was caused by an other bug, this should be the final patch. There's one minor issue I couldn't solve: The temporary created file can't be deleted because the ZipFile can't be closed. A ZipEntry holds a reference to the original ZipFile , so closing it too early would break the ZipEntry . The result is a warning-message that the file couldn't be deleted. Once the jvm has finished, the file is released and can be removed.

People

  • Assignee:
    Unassigned
    Reporter:
    Sergey Ponomarev
Vote (3)
Watch (6)

Dates

  • Created:
    Updated: