Permission issues when changing path of files in Grade Copy Task

(Robert Rogers) #1

Wasn’t really sure where best to ask this so, thought the best place was here! I have an issue with a Gradle Copy Task where I am unzipping a zip and then modifying the file paths to remove the root folder in the zip. This was a recommended workflow because the feature to elect certain sub-directories in a zip isn’t available in Gradle:

So here is my problem this is my Gradle Task:

task unpackTomcat( type: Copy ) {
  from zipTree( "/Users/x/Downloads/" )
  into "/app/tomcat"
  fileMode 0660
  dirMode 0750
  includeEmptyDirs = false 
  eachFile { details ->
    def path = details.path
    details.path = path.substring( path.indexOf( '/' ) + 1 )

This will unpack the zip and move all files out of the apache-tomcat-X folder and put them in my base folder. IE remove the first part of the path. However when it does this the permissions on the folders are incorrect:

drwxr-xr-x   3 X  X   102B Oct 12 13:58 temp/
drwxr-xr-x  27 X  X   918B Oct 12 13:58 lib/
drwxr-xr-x  12 X  X   408B Oct 12 13:58 conf/
drwxr-xr-x  25 X  X   850B Oct 12 13:58 bin/
-rw-rw----   1 X  X   1.7K Oct 12 13:58 NOTICE
-rw-rw----   1 X  X    57K Oct 12 13:58 LICENSE
drwxr-x---   3 X  X   102B Oct 12 13:58 ../
drwxr-x---   8 X  X   272B Oct 12 13:58 ./

Even setting a umask to 027 (Trying to remove other permissions from the files/directory) on the Gradle JVM doesn’t even stop this (This should force the JVM to use the permissions of UMASK is there is no filemode set. If I remove the eachFile part of the above task the folders have the right permissions, but obviously would be in the apache-tomcat-X folder that gets created which I don’t want to occur.

So I am at a lose as to why this is happening and would love people more experienced with Gradle to help me out here. It appears that the issue is that path change causes the folders to be created with my base UMASK instead of the UMASK that is supposed to be used and this appears to be a bug but thought I would check here.

I have logged this issue about these occurrences here:
However am trying to identify a crafty solution in the meantime to get past this problem that will honor filesystem permissions.