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

          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.

          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.

          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.

          Sami Tikka added a comment - - edited

          I have to re-verify what I wrote.

          Sami Tikka added a comment - - edited I have to re-verify what I wrote.

          Olaf Lenz added a comment -

          I like to add: the problem seems to be unpacking the workspace, because if I manually unpack the file workspace.zip in the jobs subdir, the permissions are correctly retained.

          Olaf Lenz added a comment - I like to add: the problem seems to be unpacking the workspace, because if I manually unpack the file workspace.zip in the jobs subdir, the permissions are correctly retained.

          I have retested the code with my snapshot build. Here is the output of ls -l on the child job (ignore the "hudson" user - I've had hudson before jenkins came out):

          Started by upstream project "test-zip-step1" build number 18
          Building remotely on pink
          [test-zip-step2] $ /bin/sh -xe /tmp/hudson3057288463521800811.sh
          + ls -l
          total 8
          -rwxr-xr-x 1 hudson hudson 11 Sep 27 12:09 executable
          rw-rr- 1 hudson hudson 8 Sep 27 12:09 regular
          Finished: SUCCESS

          Here is the "build script" of test-zip-step1:

          #!/bin/sh
          rm -f $WORKSPACE/*
          echo "regular" > $WORKSPACE/regular
          echo "executable" > $WORKSPACE/executable

          chmod 644 $WORKSPACE/regular
          chmod 755 $WORKSPACE/executable

          I'm using the Clone Workspace SCM 0.3 to move the workspace between test-zip-step1 and test-zip-step2.

          Ciprian Ciubotariu added a comment - I have retested the code with my snapshot build. Here is the output of ls -l on the child job (ignore the "hudson" user - I've had hudson before jenkins came out): Started by upstream project "test-zip-step1" build number 18 Building remotely on pink [test-zip-step2] $ /bin/sh -xe /tmp/hudson3057288463521800811.sh + ls -l total 8 -rwxr-xr-x 1 hudson hudson 11 Sep 27 12:09 executable rw-r r - 1 hudson hudson 8 Sep 27 12:09 regular Finished: SUCCESS Here is the "build script" of test-zip-step1: #!/bin/sh rm -f $WORKSPACE/* echo "regular" > $WORKSPACE/regular echo "executable" > $WORKSPACE/executable chmod 644 $WORKSPACE/regular chmod 755 $WORKSPACE/executable I'm using the Clone Workspace SCM 0.3 to move the workspace between test-zip-step1 and test-zip-step2.

          Olaf Lenz added a comment -

          Very strange. I have rechecked everything I did as thoroughly as possible.
          If I unpack workspace.zip manually at the same location, using the jenkins user, test.sh does have the execute permission.
          If Jenkins does it, it does not have the execute permission.

          Also, I do not see any warning in the Log file, as I would expect if setting the permissions would fail.

          I'm using the Clone Workspace Plugin 0.3, Jenkins 1.431.

          Is it possible that some kind of security mechanism prevents java from creating files with execute permission?

          Olaf Lenz added a comment - Very strange. I have rechecked everything I did as thoroughly as possible. If I unpack workspace.zip manually at the same location, using the jenkins user, test.sh does have the execute permission. If Jenkins does it, it does not have the execute permission. Also, I do not see any warning in the Log file, as I would expect if setting the permissions would fail. I'm using the Clone Workspace Plugin 0.3, Jenkins 1.431. Is it possible that some kind of security mechanism prevents java from creating files with execute permission?

          Ciprian Ciubotariu added a comment - - edited

          After installing the jenkins-1.431.war from jenkins-ci.org, permissions no longer work when unzipping:

          Started by upstream project "test-zip-step1" build number 19
          Building remotely on pink
          [test-zip-step2] $ /bin/sh -xe /tmp/hudson3318659544989585823.sh
          + ls -l
          total 8
          rw-rr- 1 hudson hudson 11 Sep 27 12:49 executable
          rw-rr- 1 hudson hudson 8 Sep 27 12:49 regular
          Finished: SUCCESS

          I'll try a bisect later on.

          Ciprian Ciubotariu added a comment - - edited After installing the jenkins-1.431.war from jenkins-ci.org, permissions no longer work when unzipping: Started by upstream project "test-zip-step1" build number 19 Building remotely on pink [test-zip-step2] $ /bin/sh -xe /tmp/hudson3318659544989585823.sh + ls -l total 8 rw-r r - 1 hudson hudson 11 Sep 27 12:49 executable rw-r r - 1 hudson hudson 8 Sep 27 12:49 regular Finished: SUCCESS I'll try a bisect later on.

          Ciprian Ciubotariu added a comment - - edited

          Working with jenkins-1.432.war.

          Maybe a testcase would help. However, I am not equipped to add one to jenkins.

          Seems I'm going to stay with 1.432 for now.

          Ciprian Ciubotariu added a comment - - edited Working with jenkins-1.432.war. Maybe a testcase would help. However, I am not equipped to add one to jenkins. Seems I'm going to stay with 1.432 for now.

          Olaf Lenz added a comment - - edited

          Yes! I can confirm. I just updated to 1.432, and now it works. I assume that this was a bug in the ChangeLog, then. I think the bug can be closed. Thanks for the good work!

          Olaf Lenz added a comment - - edited Yes! I can confirm. I just updated to 1.432, and now it works. I assume that this was a bug in the ChangeLog, then. I think the bug can be closed. Thanks for the good work!

          Olaf Lenz added a comment -

          Bug is solved with 1.432. However, already 1.431 claimed to have it solved.

          Olaf Lenz added a comment - Bug is solved with 1.432. However, already 1.431 claimed to have it solved.

          Ciprian Ciubotariu added a comment - - edited

          Not sure if I need to reopen this bug, but since the change I introduced is responsible...

          My patch calls f.chmod() right after calling f.setLastModified(). This may change the last modified timestamp of the file to time of the chmod.

          I apologize for the inconveniences this may have caused.

          Ciprian Ciubotariu added a comment - - edited Not sure if I need to reopen this bug, but since the change I introduced is responsible... My patch calls f.chmod() right after calling f.setLastModified(). This may change the last modified timestamp of the file to time of the chmod. I apologize for the inconveniences this may have caused.

          Ciprian Ciubotariu added a comment - See https://github.com/jenkinsci/jenkins/pull/265

          Code changed in jenkins
          User: Seiji Sogabe
          Path:
          core/src/main/java/hudson/FilePath.java
          http://jenkins-ci.org/commit/jenkins/2bd40df44439ae04ecc2db306de70230f520c1a7
          Log:
          Merge pull request #265 from CMoH/jenkins-9577

          JENKINS-9577 Fix last modification timestamp after unzip

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Seiji Sogabe Path: core/src/main/java/hudson/FilePath.java http://jenkins-ci.org/commit/jenkins/2bd40df44439ae04ecc2db306de70230f520c1a7 Log: Merge pull request #265 from CMoH/jenkins-9577 JENKINS-9577 Fix last modification timestamp after unzip

          dogfood added a comment -

          Integrated in jenkins_main_trunk #1180
          JENKINS-9577 Fix last modification timestamp after unzip

          Ciprian Ciubotariu : f967feaca9836eb4295b588482d2fba27e59e8c1
          Files :

          • core/src/main/java/hudson/FilePath.java

          dogfood added a comment - Integrated in jenkins_main_trunk #1180 JENKINS-9577 Fix last modification timestamp after unzip Ciprian Ciubotariu : f967feaca9836eb4295b588482d2fba27e59e8c1 Files : core/src/main/java/hudson/FilePath.java

          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.

          Code changed in jenkins
          User: Andrew Bayer
          Path:
          src/main/java/hudson/plugins/cloneworkspace/CloneWorkspacePublisher.java
          src/main/java/hudson/plugins/cloneworkspace/CloneWorkspaceSCM.java
          src/main/java/hudson/plugins/cloneworkspace/CloneWorkspaceUtil.java
          src/main/resources/hudson/plugins/cloneworkspace/CloneWorkspacePublisher/config.jelly
          src/main/webapp/archiveMethod.html
          src/main/webapp/workspaceExcludeGlob.html
          http://jenkins-ci.org/commit/jenkins-clone-workspace-scm-plugin/46807bc668132b4e916dd275f77fb20efc88553e
          Log:
          Merge pull request #1 from dkruger/master

          Proposed fixes for JENKINS-9582 and JENKINS-9577

          Compare: https://github.com/jenkinsci/jenkins-clone-workspace-scm-plugin/compare/8c64c38...46807bc

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Andrew Bayer Path: src/main/java/hudson/plugins/cloneworkspace/CloneWorkspacePublisher.java src/main/java/hudson/plugins/cloneworkspace/CloneWorkspaceSCM.java src/main/java/hudson/plugins/cloneworkspace/CloneWorkspaceUtil.java src/main/resources/hudson/plugins/cloneworkspace/CloneWorkspacePublisher/config.jelly src/main/webapp/archiveMethod.html src/main/webapp/workspaceExcludeGlob.html http://jenkins-ci.org/commit/jenkins-clone-workspace-scm-plugin/46807bc668132b4e916dd275f77fb20efc88553e Log: Merge pull request #1 from dkruger/master Proposed fixes for JENKINS-9582 and JENKINS-9577 Compare: https://github.com/jenkinsci/jenkins-clone-workspace-scm-plugin/compare/8c64c38...46807bc

          Code changed in jenkins
          User: Andrew Bayer
          Path:
          src/main/java/hudson/plugins/cloneworkspace/CloneWorkspacePublisher.java
          src/main/resources/hudson/plugins/cloneworkspace/CloneWorkspacePublisher/config.jelly
          src/test/java/hudson/plugins/cloneworkspace/CloneWorkspaceSCMTest.java
          http://jenkins-ci.org/commit/jenkins-clone-workspace-scm-plugin/a92fbe254e800b81720f91f2dcde09ffcf92b5d4
          Log:
          Fixing test compilation due to changes for JENKINS-9582 and JENKINS-9577.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Andrew Bayer Path: src/main/java/hudson/plugins/cloneworkspace/CloneWorkspacePublisher.java src/main/resources/hudson/plugins/cloneworkspace/CloneWorkspacePublisher/config.jelly src/test/java/hudson/plugins/cloneworkspace/CloneWorkspaceSCMTest.java http://jenkins-ci.org/commit/jenkins-clone-workspace-scm-plugin/a92fbe254e800b81720f91f2dcde09ffcf92b5d4 Log: Fixing test compilation due to changes for JENKINS-9582 and JENKINS-9577 .

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

              Created:
              Updated:
              Resolved: