Having a problem setting custom fileMode in a copy task

(Doug Lethin) #1

I have a build which has a task to copy a src directory to a target directory. We use perforce as our source code repository, which means that unless we have checked out a file for editing, it will be marked as read-only. By default, the Copy task preserves permissions, so the target files will be read only. But, if we checkout the source file and edit it and rerun this gradle task, we will get an exception, because we can’t overwrite the file marked as read only.

I initially worked around this by adding fileMode 777 to the copy task. But this is not ideal, as it then marks the files as executable.

I would rather implement some kind of java solution where I can essentially mimic unix ‘chmod +w file’

I thought I could do by passing eachFile a closure in the copy task. But this is having unexpected results.

Here is a code snip –

// this is in a custom plugin I'm writing
    project.task([type: Copy], "customTask") {
      from {"${project.devops.confSrcDir}" }
      into { "${project.devops.confTgtDir}" }
        eachFile { details ->
        println "${details.mode} ${details.name}"

Right now, my eachFile is not doing anything other than displaying the mode, but that is where I get weird results –

Here are the permissions of some source files:


And here is what gets displayed when I run my build:

365 client-config.wsdd
292 client_sign.properties
292 bin_ranges.txt
420 dummy.txt

I would think I would get the following results:

555 client-config.wsdd
444 client_sign.properties
444 bin_ranges.txt
644 dummy.txt

For what its worth, I’m on gradle 1.4 on mac running

Are unix file modes working correctly in Gradle?



The numbers ‘555’, ‘444’ etc that commonly represent permissions are ‘octal’ representations. By default, the toString() representation is ‘decimal’ in Groovy (and Java). You’ll need to use:


to see the values as you expect.

(Doug Lethin) #3

Sometimes its hard to believe I’ve been programming in Java for over 13 years now when I trip over fundamental things such as this :frowning: Your suggestion worked like a charm.

Once again, I’m blown away by all the simple hooks Gradle provides to do things like this I couldn’t imagine doing in ant and maven. And your documentation and forum support are excellent too.

Thanks again, and we’ll be seeing you at the Gradle Summit in June.