The clone workspace plugin doesn't seem to preserve the permissions of the files in the cloned workspace.
      How to reproduce:

      • set up a job that stores the workspace
      • create a shell script with "execution" permission in the workspace
      • run the job
      • create a job that clones the workspace
      • run the job
      • examine the permissions of the script: the execution permission is gone

          [JENKINS-9577] Clone workspace does not preserve permissions

          Olaf Lenz created issue -
          Uwe Stuehler made changes -
          Link New: This issue is related to JENKINS-9397 [ JENKINS-9397 ]

          David Kruger added a comment -

          Put in a pull request for a proposed fix: https://github.com/jenkinsci/jenkins-clone-workspace-scm-plugin/pull/1

          The TarArchiver and ZipArchiver are not being used by this plugin (though I guess they could be).

          David Kruger added a comment - Put in a pull request for a proposed fix: https://github.com/jenkinsci/jenkins-clone-workspace-scm-plugin/pull/1 The TarArchiver and ZipArchiver are not being used by this plugin (though I guess they could be).

          Alternative fix by using Ant's zip implementation in Filepath.unzip:

          https://github.com/jenkinsci/jenkins/pull/236

          Ciprian Ciubotariu added a comment - Alternative fix by using Ant's zip implementation in Filepath.unzip: https://github.com/jenkinsci/jenkins/pull/236

          Code changed in jenkins
          User: Ciprian Ciubotariu
          Path:
          changelog.html
          core/src/main/java/hudson/FilePath.java
          http://jenkins-ci.org/commit/jenkins/37a22a1cacc756fc9f1e6e6c3a0a7fa882e19944
          Log:
          [FIXED JENKINS-9577] Apply file permissions from zip archives

          Using the zip support classes just like Ant does in order to apply
          permissions. As a side-effect, remote streams need to be stored in a
          temporary file before actually unzipping them.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Ciprian Ciubotariu Path: changelog.html core/src/main/java/hudson/FilePath.java http://jenkins-ci.org/commit/jenkins/37a22a1cacc756fc9f1e6e6c3a0a7fa882e19944 Log: [FIXED JENKINS-9577] Apply file permissions from zip archives Using the zip support classes just like Ant does in order to apply permissions. As a side-effect, remote streams need to be stored in a temporary file before actually unzipping them.
          SCM/JIRA link daemon made changes -
          Resolution New: Fixed [ 1 ]
          Status Original: Open [ 1 ] New: Resolved [ 5 ]

          dogfood added a comment -

          dogfood added a comment - Integrated in jenkins_main_trunk #1129

          Olaf Lenz added a comment -

          I'm sorry to say that this does not seem to have fixed the bug.
          I'm running 1.431 on a Linux machine, and just to test the bug, I have created two test jobs, one that creates a file with execute permissions and packs it into a workspace, and one which simply unpacks the workspace and runs 'ls -l':

          http://espressomd.org/jenkins/view/All/job/Test-pack/
          http://espressomd.org/jenkins/view/All/job/Test-unpack/

          After unpacking, the execute permission of "test.sh" is gone.

          Olaf Lenz added a comment - I'm sorry to say that this does not seem to have fixed the bug. I'm running 1.431 on a Linux machine, and just to test the bug, I have created two test jobs, one that creates a file with execute permissions and packs it into a workspace, and one which simply unpacks the workspace and runs 'ls -l': http://espressomd.org/jenkins/view/All/job/Test-pack/ http://espressomd.org/jenkins/view/All/job/Test-unpack/ After unpacking, the execute permission of "test.sh" is gone.
          Olaf Lenz made changes -
          Resolution Original: Fixed [ 1 ]
          Status Original: Resolved [ 5 ] New: Reopened [ 4 ]

          Owen Mehegan added a comment -

          I can confirm this is not fixed. I installed 1.431 and ran the same test that Olaf did, and I also see that the file does not have executable permissions after the copy.

          Owen Mehegan added a comment - I can confirm this is not fixed. I installed 1.431 and ran the same test that Olaf did, and I also see that the file does not have executable permissions after the copy.

            olenz Olaf Lenz
            olenz Olaf Lenz
            Votes:
            3 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: