-
Bug
-
Resolution: Fixed
-
Critical
-
None
Moved from Copy Artifact 1.20 to 1.21 today, and was greeted with a build-breaking bug. Basic scenario: Windows master, two linux slaves. Build A runs on slave and generates artifact foo/bar.txt . Build B runs and copies the artifacts from build A into directory A-artifacts. A-artifacts directory ends up with a file "foo\bar.txt" (with a literal backslash in the file name), instead of directory "foo" containing file "bar.txt".
- is related to
-
-
- Closed
-
[JENKINS-12412] copyartifact 1.21 fails in at least certain cross-platform copy scenarios
This is also a problem for me. I am using Jenkins LTS release 1.424.2 and version 1.21 of the copy artifacts plug-in.
Artifacts created on a Windows slave are copied to my Linux slave with literal '/' characters in the file name.
Reverting to version 1.20 of copy artifacts fixed the problem.
All slaves involved in these builds are running the Sun JDK update 29. See attached system information details for more info on versions of other tools and plug-ins installed.
Mike Doherty
added a comment - - edited This is also a problem for me. I am using Jenkins LTS release 1.424.2 and version 1.21 of the copy artifacts plug-in.
Artifacts created on a Windows slave are copied to my Linux slave with literal '/' characters in the file name.
Reverting to version 1.20 of copy artifacts fixed the problem.
All slaves involved in these builds are running the Sun JDK update 29. See attached system information details for more info on versions of other tools and plug-ins installed. 
oeuftete
added a comment - Alan Harder:
- It did work properly in 1.20, and did so again when I rolled back the plugin.
- Using Jenkins 1.447.
- I did not upgrade the core at the same time, was already at 1.447.
oeuftete
added a comment - Alan Harder:
It did work properly in 1.20, and did so again when I rolled back the plugin.
Using Jenkins 1.447.
I did not upgrade the core at the same time, was already at 1.447.
Same here. Windows Master and Linux slaves result in foo\bar.txt files instead of foo/bar.txt file/dir structure.
i had to go back from 1.22 to 1.21 already because the plugin has another servere problem with windows nodes and timestamping,
now i have to go back another version to evade another bug 
btw, where can i get the 1.20 version of this plugin??? any help appreciated!
Alexander Dvorsky
added a comment - - edited Same here. Windows Master and Linux slaves result in foo\bar.txt files instead of foo/bar.txt file/dir structure.
i had to go back from 1.22 to 1.21 already because the plugin has another servere problem with windows nodes and timestamping,
now i have to go back another version to evade another bug
btw, where can i get the 1.20 version of this plugin??? any help appreciated! Thanks a lot. I will give it a try with 1.20.
just tried it. works. this problem does not occur with 1.20
Alexander Dvorsky
added a comment - - edited Thanks a lot. I will give it a try with 1.20.
just tried it. works. this problem does not occur with 1.20 
ikedam
added a comment - This was an issue of Jenkins core.
That is fixed in Jenkins 1.464.
See also:
JENKINS-13649
https://github.com/jenkinsci/jenkins/commit/c92c2217ecb0078f021fab7c9a053d9e63f12143
ikedam
added a comment - This was an issue of Jenkins core.
That is fixed in Jenkins 1.464.
See also:
JENKINS-13649
https://github.com/jenkinsci/jenkins/commit/c92c2217ecb0078f021fab7c9a053d9e63f12143
Did it work properly in 1.20?
What Jenkins version are you using? Did you upgrade Jenkins core at the same time?