Gradle
  1. Gradle
  2. GRADLE-971

fileMode not working for the copy task

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Resolution: Fixed
    • Affects Version/s: 0.9
    • Fix Version/s: 1.0-rc-1

      Description

      Copy's fileMode settings has no effect.

      Example:
      task test << {
      copy

      { from 'foo.txt' into 'newDir' fileMode = 0444 }

      }

      No matter which value is used (as long as it is an integer), the copied file has always the default mode.

        Activity

        Hide
        Philip Crotwell
        added a comment -


        In addition, it would be nice if the "default mode" was to use the file mode of the copied file, rather than a generic 0644. This is particularly important when copying startup shell scripts. I generate these in gradle, which is nice because I can keep the jar versions in the shell script in sync with the gradle dependencies, but then I have to do a manual "chmod a+x bin/*" every time they are regenerated. Currently the files end up with 0644 even though the original file is 0755 and the copySpec has fileMode=0755.

        Show
        Philip Crotwell
        added a comment - In addition, it would be nice if the "default mode" was to use the file mode of the copied file, rather than a generic 0644. This is particularly important when copying startup shell scripts. I generate these in gradle, which is nice because I can keep the jar versions in the shell script in sync with the gradle dependencies, but then I have to do a manual "chmod a+x bin/*" every time they are regenerated. Currently the files end up with 0644 even though the original file is 0755 and the copySpec has fileMode=0755.
        Hide
        Lars Hvile
        added a comment -

        This issue has been fixed in https://github.com/gradle/gradle/pull/62. Related to GRADLE-796 & GRADLE-673.

        Show
        Lars Hvile
        added a comment - This issue has been fixed in https://github.com/gradle/gradle/pull/62 . Related to GRADLE-796 & GRADLE-673 .
        Show
        Peter Niederwieser
        added a comment - merged https://github.com/gradle/gradle/pull/62
        Hide
        René Gröschke
        added a comment -

        Joern Huxhorn reported on the mailing list, that this bug isn't fixed yet. The original mail:

        -------------
        GRADLE-971, GRADLE-796 and GRADLE-673 are all reported as fixed in m9.

        But if I remove the doLast-workaround at https://github.com/huxi/lilith/blob/6677657bb4c9ce710d3dd2a95d61fd97fd64f7e8/config.gradle#L601 the file does still have 644 instead of 755 as permission.

        I'm not sure how to proceed… should I reopen GRADLE-971 or should I file a new bug for this problem?

        ------------------------------------------------------------
        Gradle 1.0-milestone-9
        ------------------------------------------------------------

        Gradle build time: Tuesday, March 13, 2012 4:10:09 PM UTC
        Groovy: 1.8.6
        Ant: Apache Ant(TM) version 1.8.2 compiled on December 20 2010
        Ivy: 2.2.0
        JVM: 1.6.0_29 (Apple Inc. 20.4-b02-402)
        OS: Mac OS X 10.7.3 x86_64

        Or is there anything I'm missing? I assumed that this should be fixed now. The tar task using the exact sam copyspec is working as expected.

        Cheers,
        Joern.
        -------------

        I've added a integration test to reproduce this error. (https://github.com/gradle/gradle/commit/b3e2c2a88c1e786b76b8414388037ade63c0d549)

        Show
        René Gröschke
        added a comment - Joern Huxhorn reported on the mailing list, that this bug isn't fixed yet. The original mail: ------------- GRADLE-971 , GRADLE-796 and GRADLE-673 are all reported as fixed in m9. But if I remove the doLast-workaround at https://github.com/huxi/lilith/blob/6677657bb4c9ce710d3dd2a95d61fd97fd64f7e8/config.gradle#L601 the file does still have 644 instead of 755 as permission. I'm not sure how to proceed… should I reopen GRADLE-971 or should I file a new bug for this problem? ------------------------------------------------------------ Gradle 1.0-milestone-9 ------------------------------------------------------------ Gradle build time: Tuesday, March 13, 2012 4:10:09 PM UTC Groovy: 1.8.6 Ant: Apache Ant(TM) version 1.8.2 compiled on December 20 2010 Ivy: 2.2.0 JVM: 1.6.0_29 (Apple Inc. 20.4-b02-402) OS: Mac OS X 10.7.3 x86_64 Or is there anything I'm missing? I assumed that this should be fixed now. The tar task using the exact sam copyspec is working as expected. Cheers, Joern. ------------- I've added a integration test to reproduce this error. ( https://github.com/gradle/gradle/commit/b3e2c2a88c1e786b76b8414388037ade63c0d549 )
        Hide
        Peter Niederwieser
        added a comment -

        Maybe it's only fixed for the task but not for the method.

        Show
        Peter Niederwieser
        added a comment - Maybe it's only fixed for the task but not for the method.
        Hide
        René Gröschke
        added a comment -

        No it was failing for the task and the method as tested in https://github.com/gradle/gradle/blob/master/subprojects/core/src/integTest/groovy/org/gradle/api/tasks/CopyPermissionsIntegrationTest.groovy.
        I've fixed this issue on master, maybe we can pair to review the changes.

        Show
        René Gröschke
        added a comment - No it was failing for the task and the method as tested in https://github.com/gradle/gradle/blob/master/subprojects/core/src/integTest/groovy/org/gradle/api/tasks/CopyPermissionsIntegrationTest.groovy . I've fixed this issue on master, maybe we can pair to review the changes.
        Hide
        Pablo Munoz
        added a comment - - edited

        Te suggested workaround does not work for zip tasks.

        task copy(type:Copy){
        ...
        ...
        doLast

        { File f = file('...') f.setExecutable(true, true) }


        }

        Is there a workaround for zip tasks?

        Show
        Pablo Munoz
        added a comment - - edited Te suggested workaround does not work for zip tasks. task copy(type:Copy){ ... ... doLast { File f = file('...') f.setExecutable(true, true) } } Is there a workaround for zip tasks?
        Hide
        René Gröschke
        added a comment -

        Hello Pablo,
        which version of gradle are you running. FilePermissions for Zip files should be handled correctly since M9 without the need for a workaround.
        regards,
        René

        Show
        René Gröschke
        added a comment - Hello Pablo, which version of gradle are you running. FilePermissions for Zip files should be handled correctly since M9 without the need for a workaround. regards, René
        Hide
        Pablo Munoz
        added a comment -

        Sorry, didn't see this until now. I believe we were using an earlier version. Will retest with M9 or later. Just wanted to confirm the fix would also apply to the zip tasks.

        Show
        Pablo Munoz
        added a comment - Sorry, didn't see this until now. I believe we were using an earlier version. Will retest with M9 or later. Just wanted to confirm the fix would also apply to the zip tasks.

          People

          • Assignee:
            Unassigned
            Reporter:
            Marc Guillemot
          • Votes:
            11 Vote for this issue
            Watchers:
            10 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: