Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Executing gradle spotlessApply changes permission on the changed files from 644 to 755 #654

Closed
tglaeser opened this issue Jul 29, 2020 · 4 comments · Fixed by #656
Closed

Comments

@tglaeser
Copy link
Contributor

summary of problem

Executing gradle spotlessApply changes permission on the changed files from 644 to 755

gradle or maven version

Gradle 6.5.1

spotless version

plugins {
    id 'com.diffplug.spotless' version '5.1.0'
}

operating system and version

Running MSYS2 on Windows 10

full Spotless configuration block(s)

    spotless {
        format 'misc', {
            target '*.gradle', '*.md', '*.txt', '.gitignore', '.gitattributes'
            trimTrailingWhitespace()
            indentWithSpaces()
            endWithNewline()
        }
        project.plugins.withType(JavaPlugin) {
            java {
                licenseHeaderFile(rootProject.file('copyright.txt'))
                removeUnusedImports()
            }
        }
    }

git config

$ git config --list --show-origin
...
file:.git/config        core.filemode=true
file:.git/config        core.repositoryformatversion=0
file:.git/config        core.bare=false
file:.git/config        core.logallrefupdates=true
file:.git/config        core.symlinks=false
file:.git/config        core.ignorecase=true
...

Note that the result is the same with core.filemode set to false.

@nedtwigg
Copy link
Member

Interesting! There are two tasks involved. spotless<Format> writes a correctly formatted file out to a temp location in the build folder:

public void writeCanonicalTo(File file) throws IOException {
Files.write(file.toPath(), canonicalBytes());
}

And then spotless<Format>Apply copies that file into the final locaiton

Files.copy(fileVisitDetails.getFile().toPath(), originalSource.toPath(), StandardCopyOption.REPLACE_EXISTING);

The purpose of the temp location is that it allows check and apply to depend on a single, cacheable task. Happy to take a PR to fix this.

@nedtwigg
Copy link
Member

I guess maven users probably have the same problem. The case there is a little simpler, there's no copy, just writeCanonicalTo. No obligation for a PR to fix all plugins, but I'll leave this open until it has been fixed in both plugins.

@tglaeser
Copy link
Contributor Author

tglaeser commented Aug 1, 2020

Thanks for the pointers. With java.nio.file.attribute not providing an files system agnostic file mode approach, I believe the only option then would be remembering the original file attributes by copying the original file to the temp location, updating it, and then copying it back to the final location; a PR for this is in the making.

@nedtwigg
Copy link
Member

nedtwigg commented Aug 5, 2020

Fixed in plugin-gradle 5.1.1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants