|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
Thanks for the swift investigation. As far as I can tell from my tests, the pre-1.532 did actually a deep copy of the contents of the symlink, hence instead of archiving the symlink it archived the contents of the link under the name of the link.
(In my particular case I would have a folder having
build-1.bin
build-2.bin
build-3.bin
build-4.bin
latest.bin (which points to build-4.bin) )
When I would point jenkins to 'latest.bin' (since the counter in my scenario is not know/set by jenkins) it would actually create a file called 'latest.bin' with the contents of build-4.bin, aka a deep-copy.
(I'm not saying that this behavior is 100% sane/correct/understandable, since obviously this may result in unwanted duplication of data when not done carefully, but in my case it did what it was supposed to do, and for that account the artefactdeployer plugin was doing exactly the same thing).