Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-28013

Archiving artifiacts fails with java.io.IOException: Truncated TAR archive

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Blocker Blocker
    • core
    • Jenkins 1.610 (currently most recent), Ubuntu LTS 14.04 64-bit master, SLES11 64-bit slave

      The 'archive artifacts' step of some build jobs have recently started failing with the following trace:

      Archiving artifacts
      ERROR: Failed to archive artifacts: **/*.deb, **/*.changes, **/*.rpm, **/*.egg
      java.io.IOException: Failed to extract /srv/user_name/.jenkins/workspace/SomeProject/distro/sles11_64/servertype/build/transfer of 4 files
      	at hudson.FilePath.readFromTar(FilePath.java:2299)
      	at hudson.FilePath.copyRecursiveTo(FilePath.java:2208)
      	at jenkins.model.StandardArtifactManager.archive(StandardArtifactManager.java:61)
      	at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:219)
      	at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:74)
      	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
      	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:761)
      	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:721)
      	at hudson.model.Build$BuildExecution.post2(Build.java:183)
      	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:670)
      	at hudson.model.Run.execute(Run.java:1766)
      	at hudson.matrix.MatrixRun.run(MatrixRun.java:146)
      	at hudson.model.ResourceController.execute(ResourceController.java:98)
      	at hudson.model.Executor.run(Executor.java:374)
      Caused by: java.io.IOException: Truncated TAR archive
      	at org.apache.commons.compress.archivers.tar.TarArchiveInputStream.read(TarArchiveInputStream.java:614)
      	at java.io.InputStream.read(InputStream.java:101)
      	at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1792)
      	at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1769)
      	at org.apache.commons.io.IOUtils.copy(IOUtils.java:1744)
      	at hudson.util.IOUtils.copy(IOUtils.java:40)
      	at hudson.FilePath.readFromTar(FilePath.java:2289)
      	... 13 more
      Build step 'Archive the artifacts' changed build result to FAILURE
      

      It seems that the jobs on the slaves succeeded, but the master fails:

      Apr 20, 2015 11:15:14 AM hudson.model.Run execute
      INFO: SomeProject/distro=sles11_64,servertype=build #12159 main build action completed: SUCCESS
      [... more slave SUCCESS reports ...]
      Apr 20, 2015 11:16:16 AM hudson.model.Run execute
      INFO: SomeProject #12159 main build action completed: FAILURE
      

      The master and slave logs do not show me any other errors.

      This failure occurs just for some of the slave jobs in this matrix build job. Within a specific job, this fails consistently for the same slaves, but across jobs the slaves that fail vary.

      There are no obvious resource issues; both disk space and memory usage seem to be fine.

          [JENKINS-28013] Archiving artifiacts fails with java.io.IOException: Truncated TAR archive

          Troy Mills added a comment -

          encountered the same issue, same stack. i/we had to rollback the jenkins.war on the master. environment wise, for us its CentOS6 64bit master and slaves.

          Troy Mills added a comment - encountered the same issue, same stack. i/we had to rollback the jenkins.war on the master. environment wise, for us its CentOS6 64bit master and slaves.

          Hi I have upgraded from 1.607 to 1.610. I face the same issue.
          Regards

          Laurent TOURREAU added a comment - Hi I have upgraded from 1.607 to 1.610. I face the same issue. Regards

          For the record, I'm currently using Copy Artifact Plugin 1.35.

          Downgrading to 1.609 made the issue disappear again for me.

          Steffan Karger added a comment - For the record, I'm currently using Copy Artifact Plugin 1.35. Downgrading to 1.609 made the issue disappear again for me.

          Daniel Beck added a comment -

          Probably a regression from JENKINS-10629.

          Daniel Beck added a comment - Probably a regression from JENKINS-10629 .

          @Daniel it is very unlikely that my artifacts would be > 8GB; the artifacts generated by 1.609 are ~ 1MB.

          Steffan Karger added a comment - @Daniel it is very unlikely that my artifacts would be > 8GB; the artifacts generated by 1.609 are ~ 1MB.

          Daniel Beck added a comment -

          That's why this can be considered a regression, and not just an incomplete fix. https://github.com/jenkinsci/jenkins/pull/1647 is a likely culprit.

          Daniel Beck added a comment - That's why this can be considered a regression, and not just an incomplete fix. https://github.com/jenkinsci/jenkins/pull/1647 is a likely culprit.

          Makes sense. Sorry for the noise.

          Steffan Karger added a comment - Makes sense. Sorry for the noise.

          Oleg Nenashev added a comment -

          Yes, it seems to be a regression.
          In JENKINS-10629 we ported the Tars handling implementation to apache-compress from a legacy snapshot of the library.

          It would be great to have an example of artefacts you're trying to publish.

          Oleg Nenashev added a comment - Yes, it seems to be a regression. In JENKINS-10629 we ported the Tars handling implementation to apache-compress from a legacy snapshot of the library. It would be great to have an example of artefacts you're trying to publish.

          I also started seeing this after upgrading from 1.609 to 1.610.
          Downgrading fixed the problem.

          Matthew Webber added a comment - I also started seeing this after upgrading from 1.609 to 1.610. Downgrading fixed the problem.

          It would be great to have an example of artefacts you're trying to publish

          Ours are a bit too large to attach here, but below is the directory structure:

          /exports/jenkins_home/jobs/DawnDiamond.master-create.product/builds/3053/archive]$ ls -la
          drwxrwsr-x. 2 dlshudson dls_dasc 4096 Apr 20 16:38 artifacts_to_archive
          drwxrwsr-x. 3 dlshudson dls_dasc 4096 Apr 20 16:38 create.product.root
          
          $ ls -la artifacts_to_archive/
          -rw-rw-r--. 1 dlshudson dls_dasc 6152 Apr 20 16:29 materialized_head_commits.txt
          -rw-rw-r--. 1 dlshudson dls_dasc  345 Apr 20 16:29 materialized_targetplatform_contents.txt
          
          $ ls -la create.product.root/
          drwxrwsr-x. 2 dlshudson dls_dasc 4096 Apr 20 16:40 products
          
          $ ls -la create.product.root/products/
          -rw-rw-r--. 1 dlshudson dls_dasc 482936973 Apr 20 16:25 DawnDiamond-1.9.0.v20150420-1451-linux32.zip
          -rw-rw-r--. 1 dlshudson dls_dasc 479510056 Apr 20 16:25 DawnDiamond-1.9.0.v20150420-1451-linux64.zip
          -rw-rw-r--. 1 dlshudson dls_dasc 328621190 Apr 20 16:25 DawnDiamond-1.9.0.v20150420-1451-mac64.zip
          -rw-rw-r--. 1 dlshudson dls_dasc 488357250 Apr 20 16:25 DawnDiamond-1.9.0.v20150420-1451-windows32.zip
          -rw-rw-r--. 1 dlshudson dls_dasc 494944440 Apr 20 16:25 DawnDiamond-1.9.0.v20150420-1451-windows64.zip
          -rw-rw-r--. 1 dlshudson dls_dasc        21 Apr 20 16:37 product_version_number.txt
          -rw-rw-r--. 1 dlshudson dls_dasc 104848904 Apr 20 16:37 squish_tests.zip
          -rw-rw-r--. 1 dlshudson dls_dasc 459423471 Apr 20 16:25 uk.ac.diamond.dawn.site_1.7.1.v20150420-1451.zip
          

          Matthew Webber added a comment - It would be great to have an example of artefacts you're trying to publish Ours are a bit too large to attach here, but below is the directory structure: /exports/jenkins_home/jobs/DawnDiamond.master-create.product/builds/3053/archive]$ ls -la drwxrwsr-x. 2 dlshudson dls_dasc 4096 Apr 20 16:38 artifacts_to_archive drwxrwsr-x. 3 dlshudson dls_dasc 4096 Apr 20 16:38 create.product.root $ ls -la artifacts_to_archive/ -rw-rw-r--. 1 dlshudson dls_dasc 6152 Apr 20 16:29 materialized_head_commits.txt -rw-rw-r--. 1 dlshudson dls_dasc 345 Apr 20 16:29 materialized_targetplatform_contents.txt $ ls -la create.product.root/ drwxrwsr-x. 2 dlshudson dls_dasc 4096 Apr 20 16:40 products $ ls -la create.product.root/products/ -rw-rw-r--. 1 dlshudson dls_dasc 482936973 Apr 20 16:25 DawnDiamond-1.9.0.v20150420-1451-linux32.zip -rw-rw-r--. 1 dlshudson dls_dasc 479510056 Apr 20 16:25 DawnDiamond-1.9.0.v20150420-1451-linux64.zip -rw-rw-r--. 1 dlshudson dls_dasc 328621190 Apr 20 16:25 DawnDiamond-1.9.0.v20150420-1451-mac64.zip -rw-rw-r--. 1 dlshudson dls_dasc 488357250 Apr 20 16:25 DawnDiamond-1.9.0.v20150420-1451-windows32.zip -rw-rw-r--. 1 dlshudson dls_dasc 494944440 Apr 20 16:25 DawnDiamond-1.9.0.v20150420-1451-windows64.zip -rw-rw-r--. 1 dlshudson dls_dasc 21 Apr 20 16:37 product_version_number.txt -rw-rw-r--. 1 dlshudson dls_dasc 104848904 Apr 20 16:37 squish_tests.zip -rw-rw-r--. 1 dlshudson dls_dasc 459423471 Apr 20 16:25 uk.ac.diamond.dawn.site_1.7.1.v20150420-1451.zip

          In fact, I just noticed something strange. If I go to $JENKINS_HOME/jobs on the Jenkins master, and look in <myjob>/builds/<build-number>/archive/ for the job that failed, I see all the archived files that I expect.

          It's worth noting that the failing job was running on a slave, but the slave was defined as the same machine as the master.

          Matthew Webber added a comment - In fact, I just noticed something strange. If I go to $JENKINS_HOME/jobs on the Jenkins master, and look in <myjob>/builds/<build-number>/archive/ for the job that failed, I see all the archived files that I expect. It's worth noting that the failing job was running on a slave, but the slave was defined as the same machine as the master.

          If you want to see the artefacts that I attempted to save, you can get a copy from http://www.opengda.org/downloads/special/archive.zip (be warned it's 2.1GB). Unzip that, and you will have what I was trying to archive.

          Note: job specified "files to archive" as:
          artifacts_to_archive/, create.product.root/products/.txt, create.product.root/products/*.zip

          Matthew Webber added a comment - If you want to see the artefacts that I attempted to save, you can get a copy from http://www.opengda.org/downloads/special/archive.zip (be warned it's 2.1GB). Unzip that, and you will have what I was trying to archive. Note: job specified "files to archive" as: artifacts_to_archive/ , create.product.root/products/ .txt, create.product.root/products/*.zip

          Qingyou Meng added a comment -

          Same problem on a slave node.
          Downgrade to 1.609 fixed the problem.
          size of jar files are about 1~2M
          size of a tar.gz file is about 37M

          ==== build log =====

          Notifying upstream projects of job completion
          Join notifier requires a CauseAction
          [INFO] ------------------------------------------------------------------------
          [INFO] Reactor Summary:
          [INFO]
          [INFO] web-common ........................................ SUCCESS [0.587s]
          [INFO] web-common-open ................................... SUCCESS [3.574s]
          [INFO] web-common-frontend ............................... SUCCESS [1.031s]
          [INFO] web-common-backend ................................ SUCCESS [0.808s]
          [INFO] web-common-business ............................... SUCCESS [10.231s]
          [INFO] ------------------------------------------------------------------------
          [INFO] BUILD SUCCESS
          [INFO] ------------------------------------------------------------------------
          [INFO] Total time: 19.959s
          [INFO] Finished at: Tue Apr 21 14:14:53 CST 2015
          [INFO] Final Memory: 30M/165M
          [INFO] ------------------------------------------------------------------------
          [JENKINS] Archiving /home/jenkinsslave/workspace/workspace/web_dept/web_dept__devprj/考勤v2.0/web-common/web-common-frontend/pom.xml to com.jingoal.web-common/web-common-frontend/1.0.0/web-common-frontend-1.0.0.pom
          [JENKINS] Archiving /home/jenkinsslave/workspace/workspace/web_dept/web_dept__devprj/考勤v2.0/web-common/web-common-frontend/target/web-common-frontend-1.0.0.jar to com.jingoal.web-common/web-common-frontend/1.0.0/web-common-frontend-1.0.0.jar
          [JENKINS] Archiving /home/jenkinsslave/workspace/workspace/web_dept/web_dept__devprj/考勤v2.0/web-common/web-common-frontend/target/web-common-frontend-1.0.0-sources.jar to com.jingoal.web-common/web-common-frontend/1.0.0/web-common-frontend-1.0.0-sources.jar
          ERROR: Failed to parse POMs
          java.io.IOException: Failed to extract /home/jenkinsslave/workspace/workspace/web_dept/web_dept__devprj/考勤v2.0/web-common/web-common-frontend/transfer of 3 files
          at hudson.FilePath.readFromTar(FilePath.java:2299)
          at hudson.FilePath.copyRecursiveTo(FilePath.java:2208)
          channel stopped
          at jenkins.model.StandardArtifactManager.archive(StandardArtifactManager.java:61)
          at hudson.maven.MavenBuild$ProxyImpl.performArchiving(MavenBuild.java:483)
          at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:851)
          at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:536)
          at hudson.model.Run.execute(Run.java:1741)
          at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:531)
          at hudson.model.ResourceController.execute(ResourceController.java:98)
          at hudson.model.Executor.run(Executor.java:374)
          Caused by: java.io.IOException: Truncated TAR archive
          at org.apache.commons.compress.archivers.tar.TarArchiveInputStream.read(TarArchiveInputStream.java:614)
          at java.io.InputStream.read(InputStream.java:101)
          at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1792)
          at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1769)
          at org.apache.commons.io.IOUtils.copy(IOUtils.java:1744)
          at hudson.util.IOUtils.copy(IOUtils.java:40)
          at hudson.FilePath.readFromTar(FilePath.java:2289)
          ... 9 more
          Skipping sonar analysis due to bad build status FAILURE

          Qingyou Meng added a comment - Same problem on a slave node. Downgrade to 1.609 fixed the problem. size of jar files are about 1~2M size of a tar.gz file is about 37M ==== build log ===== Notifying upstream projects of job completion Join notifier requires a CauseAction [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: [INFO] [INFO] web-common ........................................ SUCCESS [0.587s] [INFO] web-common-open ................................... SUCCESS [3.574s] [INFO] web-common-frontend ............................... SUCCESS [1.031s] [INFO] web-common-backend ................................ SUCCESS [0.808s] [INFO] web-common-business ............................... SUCCESS [10.231s] [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 19.959s [INFO] Finished at: Tue Apr 21 14:14:53 CST 2015 [INFO] Final Memory: 30M/165M [INFO] ------------------------------------------------------------------------ [JENKINS] Archiving /home/jenkinsslave/workspace/workspace/web_dept/web_dept__devprj/考勤v2.0/web-common/web-common-frontend/pom.xml to com.jingoal.web-common/web-common-frontend/1.0.0/web-common-frontend-1.0.0.pom [JENKINS] Archiving /home/jenkinsslave/workspace/workspace/web_dept/web_dept__devprj/考勤v2.0/web-common/web-common-frontend/target/web-common-frontend-1.0.0.jar to com.jingoal.web-common/web-common-frontend/1.0.0/web-common-frontend-1.0.0.jar [JENKINS] Archiving /home/jenkinsslave/workspace/workspace/web_dept/web_dept__devprj/考勤v2.0/web-common/web-common-frontend/target/web-common-frontend-1.0.0-sources.jar to com.jingoal.web-common/web-common-frontend/1.0.0/web-common-frontend-1.0.0-sources.jar ERROR: Failed to parse POMs java.io.IOException: Failed to extract /home/jenkinsslave/workspace/workspace/web_dept/web_dept__devprj/考勤v2.0/web-common/web-common-frontend/transfer of 3 files at hudson.FilePath.readFromTar(FilePath.java:2299) at hudson.FilePath.copyRecursiveTo(FilePath.java:2208) channel stopped at jenkins.model.StandardArtifactManager.archive(StandardArtifactManager.java:61) at hudson.maven.MavenBuild$ProxyImpl.performArchiving(MavenBuild.java:483) at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:851) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:536) at hudson.model.Run.execute(Run.java:1741) at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:531) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:374) Caused by: java.io.IOException: Truncated TAR archive at org.apache.commons.compress.archivers.tar.TarArchiveInputStream.read(TarArchiveInputStream.java:614) at java.io.InputStream.read(InputStream.java:101) at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1792) at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1769) at org.apache.commons.io.IOUtils.copy(IOUtils.java:1744) at hudson.util.IOUtils.copy(IOUtils.java:40) at hudson.FilePath.readFromTar(FilePath.java:2289) ... 9 more Skipping sonar analysis due to bad build status FAILURE

          Omar Kohl added a comment -

          Same issue here after upgrade to 1.610. Jenkins master running on Debian Wheezy. The artifact size is a few MB at most.

          Omar Kohl added a comment - Same issue here after upgrade to 1.610. Jenkins master running on Debian Wheezy. The artifact size is a few MB at most.

          boris ivan added a comment -

          Same issue here where build slave is Windows 2012. Artifact only a couple of MB.

          boris ivan added a comment - Same issue here where build slave is Windows 2012. Artifact only a couple of MB.

          Oleg Nenashev added a comment -

          The issue seems to be platform-independent.
          BTW, I still cannot reproduce it in unit tests

          Oleg Nenashev added a comment - The issue seems to be platform-independent. BTW, I still cannot reproduce it in unit tests

          K P added a comment -

          Same issue, identical stack trace.
          Seems to be platform independent indeed: platform is Windows server 2008. Jobs runs on slave jenkins, which runs on the same same machine (i.e. in the same Windows instance). Artifacts are rather small (.zip of 1.7 MB, .jar of merely 30 KB).
          Reverting to 1.609 restores the functionality.

          K P added a comment - Same issue, identical stack trace. Seems to be platform independent indeed: platform is Windows server 2008. Jobs runs on slave jenkins, which runs on the same same machine (i.e. in the same Windows instance). Artifacts are rather small (.zip of 1.7 MB, .jar of merely 30 KB). Reverting to 1.609 restores the functionality.

          Matt Evans added a comment -

          Same issue, same stack trace, reverted to 1.609 o fix issue.

          Matt Evans added a comment - Same issue, same stack trace, reverted to 1.609 o fix issue.

          Marcel Beister added a comment - - edited

          Same issue, same stack trace after update from 1.608 to 1.610.
          All nodes run on Windows 7 and artifacts are approximately 10 to 50 MB in size.

          Marcel Beister added a comment - - edited Same issue, same stack trace after update from 1.608 to 1.610. All nodes run on Windows 7 and artifacts are approximately 10 to 50 MB in size.

          Frank Stiller added a comment -

          The problem is not coming up on every build. I started building 5 artifacts. 3 of them failed. Have now rolled back to 1.609 as they had the exact same configuration

          Frank Stiller added a comment - The problem is not coming up on every build. I started building 5 artifacts. 3 of them failed. Have now rolled back to 1.609 as they had the exact same configuration

          Same problem. Reverted to 1.609 solved it.

          Fredrik Duprez added a comment - Same problem. Reverted to 1.609 solved it.

          Oleg Nenashev added a comment -

          I was unable to reproduce the issue on Java 6/7 and remote Windows/Ubuntu/Mac slaves. Massive load experiments didn't help as well.

          Does anybody see the issue on these Java versions? Probably, it could be something specific to Java8 or to the remoting behavior.

          Oleg Nenashev added a comment - I was unable to reproduce the issue on Java 6/7 and remote Windows/Ubuntu/Mac slaves. Massive load experiments didn't help as well. Does anybody see the issue on these Java versions? Probably, it could be something specific to Java8 or to the remoting behavior.

          Ayako Baba added a comment -

          Same problem.

          java version "1.8.0_05"
          Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
          Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)

          Ayako Baba added a comment - Same problem. java version "1.8.0_05" Java(TM) SE Runtime Environment (build 1.8.0_05-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)

          Oleg, positive. SLES 11, java 1.7.0_45-b18 - the problem appears. Not on every job though. But if the job is "cursed" then "Truncated TAR archive" on every its build.

          Andrey Regentov added a comment - Oleg, positive. SLES 11, java 1.7.0_45-b18 - the problem appears. Not on every job though. But if the job is "cursed" then "Truncated TAR archive" on every its build.

          Oleg Nenashev added a comment -

          The issue has been caused by a binary stream corruption in Tar archiving procedures.
          https://github.com/jenkinsci/jenkins/pull/1667 has been created to revert the change

          Oleg Nenashev added a comment - The issue has been caused by a binary stream corruption in Tar archiving procedures. https://github.com/jenkinsci/jenkins/pull/1667 has been created to revert the change

          I am running Java 8 on both master and slave (both Linux), and get the problem.

          From the comments on https://github.com/jenkinsci/jenkins/pull/1667, it looks the maintainers can now reproduce the problem.

          Matthew Webber added a comment - I am running Java 8 on both master and slave (both Linux), and get the problem. From the comments on https://github.com/jenkinsci/jenkins/pull/1667 , it looks the maintainers can now reproduce the problem.

          Code changed in jenkins
          User: Oleg Nenashev
          Path:
          core/pom.xml
          core/src/main/java/hudson/FilePath.java
          core/src/main/java/hudson/org/apache/tools/tar/TarInputStream.java
          core/src/main/java/hudson/org/apache/tools/tar/TarOutputStream.java
          core/src/main/java/hudson/util/io/TarArchiver.java
          http://jenkins-ci.org/commit/jenkins/ca21c65bf2538982126bd465eb70840071a61e4e
          Log:
          Merge pull request #1667 from oleg-nenashev/JENKINS-10629-FIX

          [JENKINS-28013,JENKINS-28012] - Revert changes for JENKINS-10629

          Compare: https://github.com/jenkinsci/jenkins/compare/8c94920973c4...ca21c65bf253

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Oleg Nenashev Path: core/pom.xml core/src/main/java/hudson/FilePath.java core/src/main/java/hudson/org/apache/tools/tar/TarInputStream.java core/src/main/java/hudson/org/apache/tools/tar/TarOutputStream.java core/src/main/java/hudson/util/io/TarArchiver.java http://jenkins-ci.org/commit/jenkins/ca21c65bf2538982126bd465eb70840071a61e4e Log: Merge pull request #1667 from oleg-nenashev/ JENKINS-10629 -FIX [JENKINS-28013,JENKINS-28012] - Revert changes for JENKINS-10629 Compare: https://github.com/jenkinsci/jenkins/compare/8c94920973c4...ca21c65bf253

          Daniel Beck added a comment -

          Resolved by reverting the fix for JENKINS-10629.

          Daniel Beck added a comment - Resolved by reverting the fix for JENKINS-10629 .

          Alojzij added a comment -

          Just an information, that others might find it useful.

          We had a similar stack trace, but the cause was Windows Defender, that apparently deleted the file after it was accessed for archiving. The fix was, that we had to disable "Real-time protection".

          Alojzij added a comment - Just an information, that others might find it useful. We had a similar stack trace, but the cause was Windows Defender, that apparently deleted the file after it was accessed for archiving. The fix was, that we had to disable "Real-time protection".

            oleg_nenashev Oleg Nenashev
            syzzer Steffan Karger
            Votes:
            34 Vote for this issue
            Watchers:
            52 Start watching this issue

              Created:
              Updated:
              Resolved: