[
https://issues.jenkins-ci.org/browse/JENKINS-9118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160102#comment-160102
]
SCM/JIRA link daemon commented on JENKINS-9118:
-----------------------------------------------
Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
changelog.html
core/src/main/java/hudson/FilePath.java
core/src/main/java/hudson/FileSystemProvisioner.java
http://jenkins-ci.org/commit/jenkins/2dd70965a781f3f8477ce06d1ecf61f6c3017ace
Log:
[FIXED JENKINS-9118]
WorkspaceSnapshot now uses the tar.gz format to handle symlinks
correctly.
Compare: https://github.com/jenkinsci/jenkins/compare/132f8b7...2dd7096
> When workspace is cloned, symlinks are replaced with copies of the files they
> point to
> --------------------------------------------------------------------------------------
>
> Key: JENKINS-9118
> URL: https://issues.jenkins-ci.org/browse/JENKINS-9118
> Project: Jenkins
> Issue Type: Bug
> Components: clone-workspace
> Affects Versions: current
> Environment: Linux
> Reporter: owenmehegan
> Assignee: abayer
>
> When a project uses the "clone workspace for SCM" feature to grab a workspace
> from another project, somewhere in that process all symlinks in the original
> workspace are replaced with COPIES of the files they are supposed to point
> to. These copies are then afflicted with JENKINS-8677, where their exec
> permissions are wiped out. I'm pretty sure this is related to the clone
> workspace plugin. When I look at the workspace the files are coming FROM,
> everything is fine. Then the workspace they end up in, in the job that clones
> them, shows this symlink issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
