[GRADLE-971] fileMode not working for the copy task Created: 10/Jun/10  Updated: 04/Jan/13  Resolved: 16/Mar/12

Status: Resolved
Project: Gradle
Affects Version/s: 0.9
Fix Version/s: 1.0-rc-1

Type: Bug
Reporter: Marc Guillemot Assignee: Unassigned
Resolution: Fixed Votes: 11


 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.

 Comments   
Comment by Philip Crotwell [ 29/Sep/10 ]


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.

Comment by Lars Hvile [ 15/Feb/12 ]

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

Comment by Peter Niederwieser [ 15/Feb/12 ]

merged https://github.com/gradle/gradle/pull/62

Comment by René Gröschke (Inactive) [ 15/Mar/12 ]

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)

Comment by Peter Niederwieser [ 15/Mar/12 ]

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

Comment by René Gröschke (Inactive) [ 16/Mar/12 ]

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.

Comment by Pablo Munoz [ 20/Mar/12 ]

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?

Comment by René Gröschke (Inactive) [ 20/Mar/12 ]

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é

Comment by Pablo Munoz [ 14/May/12 ]

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.

Generated at Wed Jun 30 11:43:35 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.