The process cannot access the file since gradle 8

Help/Discuss
1

Hi,
since I updated my build to gradle 8, so 8.2.1 at the moment, but also earlier on, my build construct does not work anymore.
The construct looks like this:

	task buildFeature(type: Zip) {
    	from buildNative
    	exclude '**/*project*.zip'
	}

	task buildTemplate(type: Zip) {
    	dependsOn buildNative
    	archiveClassifier = 'template'
    	from {
        	buildNative.outputs.files.asFileTree.filter {file->file.name.endsWith('_template.zip')}.collect{zipTree(it)}
    	}
	}

	task buildNative {
    	outputs.dir('out')
    	if (OperatingSystem.current().isWindows()) {
        	dependsOn 'buildwindows'
    	}
    	if (OperatingSystem.current().isLinux()) {
        	dependsOn 'buildunix'
    	}
	}

	task buildwindows(type: Exec) {
    	dependsOn extractDeps
    	commandLine 'cmd','/c', 'build.bat', version.replaceAll("-.*","")
	}

	artifacts {
    	template buildTemplate
    	feature buildFeature
	}

build.bat calls a 3rd Party Java tool to compile stuff.
With gradle 7 everythig works fine, so it was with gradle 5 and 6, but now I get

The process cannot access the file because another process has locked a portion of the file
java.io.IOException: The process cannot access the file because another process has locked a portion of the file
	at java.io.FileInputStream.readBytes(Native Method)
	at java.io.FileInputStream.read(FileInputStream.java:233)

So I suspect the outputs.dir statement in buildNative, but this is necessarry, without it, in buildTemplate there is nothing to work with.

Is there anything I could do to at least debug a little more? Some parameter to see, what file is the problem, or what folder. Or maybe someone knows about the change in gradle 8 that results in this?
Of cause this is a windows only problem, there is no issue when running this on linux.

Thanks, Stefan

2

I just tried to run with 8.4, this does not work either.
Then I tried to run 7.6.3, this is working again.
Does anyone know what changed in respect to this problem in gradle 8 or what I could do to debug my problem further? Problem here is that I don’t even know what file is locked. Or what folder.
Thanks, Stefan

3

Assuming this is reproducible, just run through a debugger and set a breakpoint?

4

OK, as those are not my tools, I can’t set breakpoints or debugging.
But I found a commandline tool that can list all locked files, so in my script I called this tool before starting the 3rd party java tool that throws this error.
What I found is the following:
With gradle 7.6.1 only the project folder is locked by several processes, nothing more.
But with gradle 8.5 also a file called $projectfolder/build/tmp/.cache/expanded/expanded.lock is created and locked.
The whole folder expanded is not created with 7.6.1.
I think it is the extractDeps-Task that creates this folder structure and the lock file.
It looks like this:

task extractDeps(type: Copy) {
    inputs.files configurations.template
    from {
        configurations.template.collect {
            if( it.exists() ) {
                zipTree( it ).matching{ include '**/*.xml' }.files
            }
        }
    }
    into( 'deps' )
}

This is only a problem if the project depend on a different project. If those dependencies are static files, everythig is fine. But if the dependency files that are extracted here have to be build before in a different project, we get this lock issue. And to stress it again, this is not a problem with gradle 7.

I’m totally sure I did not describe the problem properly, so please assk questions, so I can add missing information.

Thanks, Stefan

5

OK, as those are not my tools, I can’t set breakpoints or debugging.

Sure you can.
For example you could have breakpoint in java.io.FileInputStream.read(FileInputStream.java:233) that does not suspend but log the file of that stream, that way you would know which file is the problem.

And if a file that Gradle uses for some locking indeed is the problem, then the question might be, why that tool tries to read that file actually and it is probably not so much a Gradle question, but a question to that tool.

To work-around the problem you might maybe be able to replace the extraction logic there by an artifact transform that does the extracting and might work-around the symptom.

6

Finally I found time to dig into this problem again and could debug the code. Indeed the mentioned file expanded.lock was the problem and of course you are right, this is not a gradle problem.
The follow up java process tries to zip the whole project folder and so also this file.
I could find some hidden configuration to switch off the project folder zipping, that I do not need at all, and so, case closed.
Thanks again.

1 Like