Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-12628

Executable file permission not set anymore

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: cvs-plugin
    • Labels:
      None
    • Environment:
      CentOS release 5.7 (affected system, Slave), Windows Server 2003 (Master)
    • Similar Issues:

      Description

      Updating the cvs plugin from 1.6 to 2.0 breaks all our linux builds, due the fact that our compile scripts don't have executable permission bit set anymore. The bit is correctly set on the affected files on cvs server side.

      cvs plugin 1.6:
      rwxrwx-- 1 jenkins jenkins 261 15. Mai 2007 compile.linux.so.release

      cvs plugin 2.0:
      rw-rw-r- 1 jenkins jenkins 261 15. Mai 2007 compile.linux.so.release

        Attachments

          Activity

          mborm Marco Borm created issue -
          Hide
          alexlehm Alex Lehmann added a comment -

          I wonder if that is an issue with the pure java cvs client, since Java doesn't handle unix permissions properly (or most programs don't before java 7)

          Show
          alexlehm Alex Lehmann added a comment - I wonder if that is an issue with the pure java cvs client, since Java doesn't handle unix permissions properly (or most programs don't before java 7)
          Hide
          mc1arke Michael Clarke added a comment -

          The cvs client doesn't do anything with permission just now. It's possible to use File.setExecutable() providing I can work out what response from the server specifies the permission. There is an outstanding Netbeans issues for this which no-one seems to have done any work on (I don't have the details to hand though).

          Show
          mc1arke Michael Clarke added a comment - The cvs client doesn't do anything with permission just now. It's possible to use File.setExecutable() providing I can work out what response from the server specifies the permission. There is an outstanding Netbeans issues for this which no-one seems to have done any work on (I don't have the details to hand though).
          Hide
          alexlehm Alex Lehmann added a comment -

          From what I found in the source code for cvslib, the library doesn't implement unix permissions, so this is outside the scope of the plugin.

          Show
          alexlehm Alex Lehmann added a comment - From what I found in the source code for cvslib, the library doesn't implement unix permissions, so this is outside the scope of the plugin.
          Hide
          alexlehm Alex Lehmann added a comment -

          I have to admit that I wasn't aware of the file execute property in java 6, that should be possible to implement (is an issue for the library though I guess).

          Jenkins is still supporting Java 5, though I think.

          Show
          alexlehm Alex Lehmann added a comment - I have to admit that I wasn't aware of the file execute property in java 6, that should be possible to implement (is an issue for the library though I guess). Jenkins is still supporting Java 5, though I think.
          Hide
          mborm Marco Borm added a comment -

          I'm a C++, not a Java developer: Maybe a call to chmod could a solution if the java cvslib runs on Java 5?

          Show
          mborm Marco Borm added a comment - I'm a C++, not a Java developer: Maybe a call to chmod could a solution if the java cvslib runs on Java 5?
          Hide
          mc1arke Michael Clarke added a comment -

          I'd personally rather not have to make system calls (such as chmod) as you're relying on a *nix system which is more of a barrier than relying on having Java 6. I'd prefer to call Java 6 methods and have a fallback if they're not available (Kohsuke wrote a blog post on Jenkins doing this a while back: http://weblogs.java.net/blog/2008/11/14/compiling-jdk6-and-running-jdk5). If we were to implement such a feature then I'd look to having a user warned that files would not be set as executable through a console message or even a warning on the CVS section of the job's config screen. Any thoughts?

          Show
          mc1arke Michael Clarke added a comment - I'd personally rather not have to make system calls (such as chmod) as you're relying on a *nix system which is more of a barrier than relying on having Java 6. I'd prefer to call Java 6 methods and have a fallback if they're not available (Kohsuke wrote a blog post on Jenkins doing this a while back: http://weblogs.java.net/blog/2008/11/14/compiling-jdk6-and-running-jdk5 ). If we were to implement such a feature then I'd look to having a user warned that files would not be set as executable through a console message or even a warning on the CVS section of the job's config screen. Any thoughts?
          Hide
          alexlehm Alex Lehmann added a comment - - edited

          chmod isn't necessary on windows anyway, if you have a wrapper the checks if the target system is unix-like and run chmod or do nothing otherwise

          if it is possible to check for java5/java6, this could be used before if possible, something like this

          if(isUnix) {
            if(isJava6) {
              File.setExecutable();
            } else {
              System.execute("chmod ...");
            }
          } else {
            warn("ignoring execute permission for ...");
          }
          
          

          if this is properly wrapped in a method, this will not even look bad in the actual code since that only has to do Wrapper.setExecutable(file);

          Show
          alexlehm Alex Lehmann added a comment - - edited chmod isn't necessary on windows anyway, if you have a wrapper the checks if the target system is unix-like and run chmod or do nothing otherwise if it is possible to check for java5/java6, this could be used before if possible, something like this if (isUnix) { if (isJava6) { File.setExecutable(); } else { System .execute( "chmod ..." ); } } else { warn( "ignoring execute permission for ..." ); } if this is properly wrapped in a method, this will not even look bad in the actual code since that only has to do Wrapper.setExecutable(file);
          Hide
          alexlehm Alex Lehmann added a comment -

          I found a similar function in Jenkins that makes a file writable using shell chmod, jdk6 and even libc chmod, maybe we could use this for changing execute permissions.

          take a look at jenkins/core hudson/Util.java#makeWritable(File f)

          Show
          alexlehm Alex Lehmann added a comment - I found a similar function in Jenkins that makes a file writable using shell chmod, jdk6 and even libc chmod, maybe we could use this for changing execute permissions. take a look at jenkins/core hudson/Util.java#makeWritable(File f)
          Hide
          mc1arke Michael Clarke added a comment -

          Unfortunately that method is private and only caters for writeable, not executable. I'd also like to try and get the patches to Cvs client merged into the upstream project which would mean we couldn't add dependencies on the Jenkins core as this would require distributing Jenkins with Netbeans.

          Cvs-plugin has been compiled to Java 1.6 since version 1.3 (9 months ago) so it would be safe to make the underlying client use the File.setExecutable() method and compile it at Java 1.6 too. Unless there's any objections to this then I'll use the File methods and have no handling for Java fall back (i.e. users must use Java 1.6 or above).

          Show
          mc1arke Michael Clarke added a comment - Unfortunately that method is private and only caters for writeable, not executable. I'd also like to try and get the patches to Cvs client merged into the upstream project which would mean we couldn't add dependencies on the Jenkins core as this would require distributing Jenkins with Netbeans. Cvs-plugin has been compiled to Java 1.6 since version 1.3 (9 months ago) so it would be safe to make the underlying client use the File.setExecutable() method and compile it at Java 1.6 too. Unless there's any objections to this then I'll use the File methods and have no handling for Java fall back (i.e. users must use Java 1.6 or above).
          Hide
          mborm Marco Borm added a comment -

          For me, Java 1.6 is ok.
          I am wondering if nobody else checks out executable scripts on Linux/Unix and has broken build service with the new release.

          Show
          mborm Marco Borm added a comment - For me, Java 1.6 is ok. I am wondering if nobody else checks out executable scripts on Linux/Unix and has broken build service with the new release.
          Hide
          alexlehm Alex Lehmann added a comment - - edited

          I guess most cvs users may not updated to 2.0

          currently this is notified by the update center but the jenkins distribution still contains 1.6

          (java 1.6 is fine with me as well, I started using Tomcat 7 a while ago, that is Java 1.6 anyway)

          Show
          alexlehm Alex Lehmann added a comment - - edited I guess most cvs users may not updated to 2.0 currently this is notified by the update center but the jenkins distribution still contains 1.6 (java 1.6 is fine with me as well, I started using Tomcat 7 a while ago, that is Java 1.6 anyway)
          mc1arke Michael Clarke made changes -
          Field Original Value New Value
          Assignee Michael Clarke [ mc1arke ]
          mc1arke Michael Clarke made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Michael Clarke
          Path:
          pom.xml
          http://jenkins-ci.org/commit/cvs-plugin/50d22a4953688f2ead47eba4f3608de63fef5a2c
          Log:
          [FIXED JENKINS-12628] - Upgrading to CVS client with permission support
          [FIXED JENKINS-12599] - Upgrading to CVS client with ext support

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Michael Clarke Path: pom.xml http://jenkins-ci.org/commit/cvs-plugin/50d22a4953688f2ead47eba4f3608de63fef5a2c Log: [FIXED JENKINS-12628] - Upgrading to CVS client with permission support [FIXED JENKINS-12599] - Upgrading to CVS client with ext support
          Hide
          dogfood dogfood added a comment -

          Integrated in plugins_cvs #9
          [FIXED JENKINS-12628] - Upgrading to CVS client with permission support (Revision 50d22a4953688f2ead47eba4f3608de63fef5a2c)

          Result = SUCCESS
          michael.m.clarke :
          Files :

          • pom.xml
          Show
          dogfood dogfood added a comment - Integrated in plugins_cvs #9 [FIXED JENKINS-12628] - Upgrading to CVS client with permission support (Revision 50d22a4953688f2ead47eba4f3608de63fef5a2c) Result = SUCCESS michael.m.clarke : Files : pom.xml
          Hide
          fredg Fred G added a comment -

          Here is the stacktrace with Java 1.5 on a Solaris Sparc machine (tested with 2.1-snapshot release):

          hudson.util.IOException2: remote file operation failed: <matrix job label> 
          at hudson.remoting.Channel@1273510:Solaris_Sparc_Slave
             at hudson.FilePath.act(FilePath.java:780)
             at hudson.FilePath.act(FilePath.java:766)
             at hudson.scm.CVSSCM.perform(CVSSCM.java:871)
             at hudson.scm.CVSSCM.checkout(CVSSCM.java:803)
             at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
             at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:573)
             at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:462)
             at hudson.model.Run.run(Run.java:1404)
             at hudson.matrix.MatrixRun.run(MatrixRun.java:146)
             at hudson.model.ResourceController.execute(ResourceController.java:88)
             at hudson.model.Executor.run(Executor.java:238)
          Caused by: java.io.IOException: Remote call on Solaris_Sparc_Slave failed
             at hudson.remoting.Channel.call(Channel.java:690)
             at hudson.FilePath.act(FilePath.java:773)
             ... 10 more
          Caused by: java.lang.NoSuchMethodError: java.io.File.setReadable(ZZ)Z
             at org.netbeans.lib.cvsclient.file.DefaultFileHandler.setFileMode(DefaultFileHandler.java:589)
             at org.netbeans.lib.cvsclient.file.DefaultFileHandler.writeAndPostProcessTextFile(DefaultFileHandler.java:341)
             at org.netbeans.lib.cvsclient.file.DefaultFileHandler.writeTextFile(DefaultFileHandler.java:303)
             at org.netbeans.lib.cvsclient.response.UpdatedResponse.process(UpdatedResponse.java:178)
             at org.netbeans.lib.cvsclient.response.CreatedResponse.process(CreatedResponse.java:54)
             at org.netbeans.lib.cvsclient.Client.handleResponse(Client.java:648)
             at org.netbeans.lib.cvsclient.Client.processRequests(Client.java:598)
             at org.netbeans.lib.cvsclient.command.checkout.CheckoutCommand.postExpansionExecute(CheckoutCommand.java:462)
             at org.netbeans.lib.cvsclient.command.checkout.CheckoutCommand.execute(CheckoutCommand.java:355)
             at org.netbeans.lib.cvsclient.Client.executeCommand(Client.java:710)
             at hudson.scm.CVSSCM$2.invoke(CVSSCM.java:891)
             at hudson.scm.CVSSCM$2.invoke(CVSSCM.java:871)
             at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2045)
             at hudson.remoting.UserRequest.perform(UserRequest.java:118)
             at hudson.remoting.UserRequest.perform(UserRequest.java:48)
             at hudson.remoting.Request$2.run(Request.java:287)
             at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
             at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
             at java.util.concurrent.FutureTask.run(FutureTask.java:123)
             at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
             at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
             at java.lang.Thread.run(Thread.java:595)
          
          Show
          fredg Fred G added a comment - Here is the stacktrace with Java 1.5 on a Solaris Sparc machine (tested with 2.1-snapshot release): hudson.util.IOException2: remote file operation failed: <matrix job label> at hudson.remoting.Channel@1273510:Solaris_Sparc_Slave at hudson.FilePath.act(FilePath.java:780) at hudson.FilePath.act(FilePath.java:766) at hudson.scm.CVSSCM.perform(CVSSCM.java:871) at hudson.scm.CVSSCM.checkout(CVSSCM.java:803) at hudson.model.AbstractProject.checkout(AbstractProject.java:1195) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:573) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:462) at hudson.model.Run.run(Run.java:1404) at hudson.matrix.MatrixRun.run(MatrixRun.java:146) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) Caused by: java.io.IOException: Remote call on Solaris_Sparc_Slave failed at hudson.remoting.Channel.call(Channel.java:690) at hudson.FilePath.act(FilePath.java:773) ... 10 more Caused by: java.lang.NoSuchMethodError: java.io.File.setReadable(ZZ)Z at org.netbeans.lib.cvsclient.file.DefaultFileHandler.setFileMode(DefaultFileHandler.java:589) at org.netbeans.lib.cvsclient.file.DefaultFileHandler.writeAndPostProcessTextFile(DefaultFileHandler.java:341) at org.netbeans.lib.cvsclient.file.DefaultFileHandler.writeTextFile(DefaultFileHandler.java:303) at org.netbeans.lib.cvsclient.response.UpdatedResponse.process(UpdatedResponse.java:178) at org.netbeans.lib.cvsclient.response.CreatedResponse.process(CreatedResponse.java:54) at org.netbeans.lib.cvsclient.Client.handleResponse(Client.java:648) at org.netbeans.lib.cvsclient.Client.processRequests(Client.java:598) at org.netbeans.lib.cvsclient.command.checkout.CheckoutCommand.postExpansionExecute(CheckoutCommand.java:462) at org.netbeans.lib.cvsclient.command.checkout.CheckoutCommand.execute(CheckoutCommand.java:355) at org.netbeans.lib.cvsclient.Client.executeCommand(Client.java:710) at hudson.scm.CVSSCM$2.invoke(CVSSCM.java:891) at hudson.scm.CVSSCM$2.invoke(CVSSCM.java:871) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2045) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:287) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269) at java.util.concurrent.FutureTask.run(FutureTask.java:123) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang. Thread .run( Thread .java:595)
          Hide
          alexlehm Alex Lehmann added a comment -

          this needs to be in a try block that catches NoSuchMethodError similar to the permission method in hudson.utils

          Show
          alexlehm Alex Lehmann added a comment - this needs to be in a try block that catches NoSuchMethodError similar to the permission method in hudson.utils
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Michael Clarke
          Path:
          pom.xml
          http://jenkins-ci.org/commit/cvs-plugin/2e658b6f4924d78603034f2209cbc2bd552369fa
          Log:
          JENKINS-12628 - Silently continue if system doesn't allow setting permissions

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Michael Clarke Path: pom.xml http://jenkins-ci.org/commit/cvs-plugin/2e658b6f4924d78603034f2209cbc2bd552369fa Log: JENKINS-12628 - Silently continue if system doesn't allow setting permissions
          Hide
          mc1arke Michael Clarke added a comment -

          File permissions are now handled in the cvsclient used by cvs-plugin as of version 2.1 providing Java 1.6 or above is being used

          Show
          mc1arke Michael Clarke added a comment - File permissions are now handled in the cvsclient used by cvs-plugin as of version 2.1 providing Java 1.6 or above is being used
          mc1arke Michael Clarke made changes -
          Status In Progress [ 3 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          rtyler R. Tyler Croy made changes -
          Workflow JNJira [ 142994 ] JNJira + In-Review [ 190379 ]

            People

            • Assignee:
              mc1arke Michael Clarke
              Reporter:
              mborm Marco Borm
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: