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

copy artifact fails on windows XP slaves due to failing to set a timestamp

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • copyartifact-plugin, core
    • None
    • Windows XP slave. CentOS 5.5 server

      The copy artifact build step fails when it trys to set the time stamp on windows XP slaves. I have attached the stack trace that shows this error
      "Caused by: java.io.IOException: Failed to set the timestamp of C:\automation\AccuNurse-3.2.0.0-569-upgrade.zip to 1316552260000"

      I believe this issue was caused by the changes made for JENKINS-10805.

      I have also found a discussion of others experiencing the same issue http://groups.google.com/group/jenkinsci-users/browse_thread/thread/249ebeb0660d5e0d/e831b70f5688d0c4?show_docid=e831b70f5688d0c4

          [JENKINS-11073] copy artifact fails on windows XP slaves due to failing to set a timestamp

          kutzi added a comment -

          Nicolas, yes there seems to be a bug in JDK with respect to setting the timestamp on Windows. However, that should be worked around in Jenkins core now.

          Bertrand, Denis, Alexander, Marnix: which Jenkins version are you using?

          kutzi added a comment - Nicolas, yes there seems to be a bug in JDK with respect to setting the timestamp on Windows. However, that should be worked around in Jenkins core now. Bertrand, Denis, Alexander, Marnix: which Jenkins version are you using?

          @kutzi: I'm not exactly sure which version of Jenkins we were using at the time we tried Copy Artifact 1.22. Most likely it was Jenkins 1.447.1, if not it was likely 1.424.6.

          Could you indicate in which versions of Jenkins core this has been worked around? Thanks!

          Marnix Klooster added a comment - @ kutzi : I'm not exactly sure which version of Jenkins we were using at the time we tried Copy Artifact 1.22. Most likely it was Jenkins 1.447.1, if not it was likely 1.424.6. Could you indicate in which versions of Jenkins core this has been worked around? Thanks!

          kutzi added a comment - - edited

          It should be fixed in 1.447 and higher http://jenkins-ci.org/changelog

          kutzi added a comment - - edited It should be fixed in 1.447 and higher http://jenkins-ci.org/changelog

          Nicolas De Loof added a comment - - edited

          @kutzi in 1.22, hudson.plugins.copyartifact.FingerprintingCopyMethod#copyOne invoke chmod and touch, it should rely on setLastModifiedIfPossible to benefits the core fixes you listed on this ticket - But this method is private

          Nicolas De Loof added a comment - - edited @kutzi in 1.22, hudson.plugins.copyartifact.FingerprintingCopyMethod#copyOne invoke chmod and touch, it should rely on setLastModifiedIfPossible to benefits the core fixes you listed on this ticket - But this method is private

          kutzi added a comment -

          @Nicolas: I don't understand, why you are not simply using FilePath.copyToWithPermission?

          kutzi added a comment - @Nicolas: I don't understand, why you are not simply using FilePath.copyToWithPermission?

          https://github.com/jenkinsci/jenkins/pull/509 to expose a public touch() method to optionally ignore windows failure on setLastModified

          Nicolas De Loof added a comment - https://github.com/jenkinsci/jenkins/pull/509 to expose a public touch() method to optionally ignore windows failure on setLastModified

          Nicolas De Loof added a comment - - edited

          @kutzi FingerprintingCopyMethod#copyOne isn't just about copying file but about copying with fingerprint to avoid duplicating fingerprint computation.
          javadoc excerpt :

          • Performs fingerprinting during the copy.
            *
          • This minimizes the cost of the fingerprinting as the I/O bound nature of the copy operation
          • masks the cost of digest computation.

          This uses copyTo(OutputStream) that has no equivalent for copyToWithPermission. Was introduced by 540a074e1b2209e0079334f93ce4266badc5e653 related to JENKINS-9741
          Maybe just safer to revert.

          Nicolas De Loof added a comment - - edited @kutzi FingerprintingCopyMethod#copyOne isn't just about copying file but about copying with fingerprint to avoid duplicating fingerprint computation. javadoc excerpt : Performs fingerprinting during the copy. * This minimizes the cost of the fingerprinting as the I/O bound nature of the copy operation masks the cost of digest computation. This uses copyTo(OutputStream) that has no equivalent for copyToWithPermission. Was introduced by 540a074e1b2209e0079334f93ce4266badc5e653 related to JENKINS-9741 Maybe just safer to revert.

          I think this is a manifestation of the same issue that caues JENKINS-11251. I claim this change in remoting fixes this. This commit will be a part of 1.473.

          Notice that all the problem reports in this bug is about remoting. Due to the asynchrony in the read/write operations in remoting vs closure calls, it was possible that the attempt to set the timestamp happens before the file is fully is written (or even before the write starts at all.)

          Kohsuke Kawaguchi added a comment - I think this is a manifestation of the same issue that caues JENKINS-11251 . I claim this change in remoting fixes this. This commit will be a part of 1.473. Notice that all the problem reports in this bug is about remoting. Due to the asynchrony in the read/write operations in remoting vs closure calls, it was possible that the attempt to set the timestamp happens before the file is fully is written (or even before the write starts at all.)

          In jenkins v1.474 this problem is still there. Overwriting existing files does not work, writing new files works fine.
          So I use the following workaround: Use a Execute Windows batch command to delete all files before copying.

          Markus Unterauer added a comment - In jenkins v1.474 this problem is still there. Overwriting existing files does not work, writing new files works fine. So I use the following workaround: Use a Execute Windows batch command to delete all files before copying.

          Marnix Klooster added a comment - - edited

          For the record: this duplicate of JENKINS-13515 has been resolved in Copy Artifact plugin 1.23/1.24; see the change log for details. And I can confirm that after switching from 1.21 to 1.28, this problem does not arise.

          Marnix Klooster added a comment - - edited For the record: this duplicate of JENKINS-13515 has been resolved in Copy Artifact plugin 1.23/1.24; see the change log for details. And I can confirm that after switching from 1.21 to 1.28, this problem does not arise.

            kohsuke Kohsuke Kawaguchi
            jkoenig Jeff Koenig
            Votes:
            20 Vote for this issue
            Watchers:
            25 Start watching this issue

              Created:
              Updated:
              Resolved: