Extracting Tomcat Zip SOMETIMES fail with IOException: Negative seek offset

Question

I am using maven cargo with its zip url installer feature to download a tomcat for my integration tests. This works fine on my computer, but when its run in husdon it fails sometimes (round about 10-20%).

The failure is:

Error while expanding /home/hudson/workspace/My Test Media-Archive/cfma/target/cargo/install/apache-tomcat-6.0.32.zip
java.io.IOException: Negative seek offset
    at org.apache.tools.ant.taskdefs.Expand.expandFile(Expand.java:148)
    at org.apache.tools.ant.taskdefs.Expand.execute(Expand.java:107)
    at org.codehaus.cargo.container.installer.ZipURLInstaller.unpack(ZipURLInstaller.java:252)
    at org.codehaus.cargo.container.installer.ZipURLInstaller.install(ZipURLInstaller.java:149)
    at org.codehaus.cargo.maven2.configuration.Container.setupHome(Container.java:357)
    at org.codehaus.cargo.maven2.configuration.Container.createContainer(Container.java:241)
    at org.codehaus.cargo.maven2.AbstractCargoMojo.createNewContainer(AbstractCargoMojo.java:470)
    at org.codehaus.cargo.maven2.AbstractCargoMojo.createContainer(AbstractCargoMojo.java:410)
    at org.codehaus.cargo.maven2.ContainerStartMojo.doExecute(ContainerStartMojo.java:53)
    at org.codehaus.cargo.maven2.AbstractCargoMojo.execute(AbstractCargoMojo.java:268)
    at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
    at hudson.maven.agent.PluginManagerInterceptor.executeMojo(PluginManagerInterceptor.java:182)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
    at org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:65)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
    at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
    at hudson.maven.agent.Main.launch(Main.java:173)
    at hudson.maven.MavenBuilder.call(MavenBuilder.java:164)
    at hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:861)
    at hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:792)
    at hudson.remoting.UserRequest.perform(UserRequest.java:114)
    at hudson.remoting.UserRequest.perform(UserRequest.java:48)
    at hudson.remoting.Request$2.run(Request.java:270)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
    at java.util.concurrent.FutureTask.run(FutureTask.java:138)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: Negative seek offset
    at java.io.RandomAccessFile.seek(Native Method)
    at org.apache.tools.zip.ZipFile.positionAtCentralDirectory(ZipFile.java:403)
    at org.apache.tools.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:271)
    at org.apache.tools.zip.ZipFile.<init>(ZipFile.java:152)
    at org.apache.tools.ant.taskdefs.Expand.expandFile(Expand.java:137)
    ... 40 more
--- Nested Exception ---
java.io.IOException: Negative seek offset
    at java.io.RandomAccessFile.seek(Native Method)
    at org.apache.tools.zip.ZipFile.positionAtCentralDirectory(ZipFile.java:403)
    at org.apache.tools.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:271)
    at org.apache.tools.zip.ZipFile.<init>(ZipFile.java:152)
    at org.apache.tools.ant.taskdefs.Expand.expandFile(Expand.java:137)
    at org.apache.tools.ant.taskdefs.Expand.execute(Expand.java:107)
    at org.codehaus.cargo.container.installer.ZipURLInstaller.unpack(ZipURLInstaller.java:252)
    at org.codehaus.cargo.container.installer.ZipURLInstaller.install(ZipURLInstaller.java:149)
    at org.codehaus.cargo.maven2.configuration.Container.setupHome(Container.java:357)
    at org.codehaus.cargo.maven2.configuration.Container.createContainer(Container.java:241)
    at org.codehaus.cargo.maven2.AbstractCargoMojo.createNewContainer(AbstractCargoMojo.java:470)
    at org.codehaus.cargo.maven2.AbstractCargoMojo.createContainer(AbstractCargoMojo.java:410)
    at org.codehaus.cargo.maven2.ContainerStartMojo.doExecute(ContainerStartMojo.java:53)
    at org.codehaus.cargo.maven2.AbstractCargoMojo.execute(AbstractCargoMojo.java:268)
    at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
    at hudson.maven.agent.PluginManagerInterceptor.executeMojo(PluginManagerInterceptor.java:182)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
    at org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:65)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
    at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
    at hudson.maven.agent.Main.launch(Main.java:173)
    at hudson.maven.MavenBuilder.call(MavenBuilder.java:164)
    at hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:861)
    at hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:792)
    at hudson.remoting.UserRequest.perform(UserRequest.java:114)
    at hudson.remoting.UserRequest.perform(UserRequest.java:48)
    at hudson.remoting.Request$2.run(Request.java:270)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
    at java.util.concurrent.FutureTask.run(FutureTask.java:138)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:662)

And this is the relevant part of my pom.

<plugin>
  <groupId>org.codehaus.cargo</groupId>
  <artifactId>cargo-maven2-plugin</artifactId>
  <version>1.0.5</version>
  <configuration>
     <container>
         <zipUrlInstaller>
    <url>http://archive.apache.org/dist/tomcat/tomcat-6/v6.0.32/bin/apache-tomcat-6.0.32.zip</url>
          <zipUrlInstaller>
          .... 
     </container>
     ...
   <configuration>
</plugin>

Does anybody know what I am doing wrong?

Similar issue happened to me when I was using `cargo:run.` I deleted the zip file and tried it again. Viola it worked. Solution: clean the temp folder and try again. — bhathiya-perera, Oct 21 '17 at 11:29

Michael · Accepted Answer · 2011-07-19T15:24:48.850

6

Usually it's due to a bad download (the odd corrupted packet etc). Try using an MD5 / SHA-1 checksum to validate the archive before using it.

Also be careful that the offset variable is large enough to hold the require value of your seek.

edited Jul 19 '11 at 15:24

answered Jul 19 '11 at 14:58

Michael

7,348
10
49
86

1

TCP should be resilient against dropped packets, surely? Only corrupted packets where the checksum verification gives a false positive should get through to the application performing the download. You could try writing a loop to wget the file and check its checksum – Peter Jul 19 '11 at 15:17
TCP should be resilient using ACK, so yes, it is more likely that corrupted packets would be the issue. – Michael Jul 19 '11 at 15:22
More likely an aborted download or a broken Maven proxy or web server that served the Tomcat download. The chance of data being corrupted when sent over TCP is very small. – Matt Ryall May 31 '13 at 00:33

score 1 · Answer 2 · answered Jul 21 '11 at 16:00

1

The Problem was gone after changing the download url to an mirror.

answered Jul 21 '11 at 16:00

Ralph

118,862
56
287
383

@Mikaveli: because I undersand your answer in the way that it is an transport problem, and second it does not contain a solution, you say only I should check the file (but I know that it is corrupt). -- But on the other hand I can accept your answer, because mine is not a real answer to the problem too. – Ralph Jul 21 '11 at 16:42
The point was, if you validated the file, you would have known whether the file was corrupt at source - or afterwards (whilst downloading / on disk etc). The final solution is determined by the result of that test. Switching the source has fixed it for you, but it's better to determine exactly where things went wrong, to protect yourself in the future. :) – Michael Jul 21 '11 at 21:53

Extracting Tomcat Zip SOMETIMES fail with IOException: Negative seek offset

2 Answers2

Linked