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

@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.)

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.

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.