Under windows, Gradle 1.11 build fails trying to generate file hashes. Related to: GRADLE-2967

Old Forum Archive
1

15:01:56.113 [ERROR] [org.gradle.BuildExceptionReporter] org.gradle.api.UncheckedIOException: java.io.IOException: The process cannot access the file because another process has locked a portion of the file 15:01:56.117 [ERROR] [org.gradle.BuildExceptionReporter]

at org.gradle.internal.hash.HashUtil.createHash(HashUtil.java:57)

Gradle is reporting this error when I try to build a native C++ lib under windows. Examining the file system access, Gradle is hashing every file stating in a path above the path where my library project is.

Z:\Work\Lib\LibUtil - library path Z:\Work\Lib - is where Gradle scans to generate the hashes.

What happens is gradle scans into the Libutil.gradle… path meaning it’s scan’s the file that stores the hashes. This is what causes the file locking problem.

I start the build inside the library path.

Z:\Work\Lib\LibUtil>gradle -d libutilStatic

3:01:56.0595643 PM java.exe 6024 CloseFile Z:\Work\Lib\LibUtil.gradle\1.11\taskArtifacts\cache.properties SUCCESS

3:01:56.0596114 PM java.exe 6024 QueryOpen Z:\Work\Lib\LibUtil.gradle\1.11\taskArtifacts\cache.properties.lock SUCCESS CreationTime: 3/24/2014 2:39:33 PM, LastAccessTime: 3/24/2014 2:39:33 PM, LastWriteTime: 3/24/2014 3:01:35 PM, ChangeTime: 3/24/2014 3:01:35 PM, AllocationSize: 56, EndOfFile: 55, FileAttributes: A 3:01:56.0596595 PM java.exe 6024 QueryOpen Z:\Work\Lib\LibUtil.gradle\1.11\taskArtifacts\cache.properties.lock SUCCESS CreationTime: 3/24/2014 2:39:33 PM, LastAccessTime: 3/24/2014 2:39:33 PM, LastWriteTime: 3/24/2014 3:01:35 PM, ChangeTime: 3/24/2014 3:01:35 PM, AllocationSize: 56, EndOfFile: 55, FileAttributes: A 3:01:56.0596980 PM java.exe 6024 CreateFile Z:\Work\Lib\LibUtil.gradle\1.11\taskArtifacts\cache.properties.lock SUCCESS Desired Access: Read Attributes, Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened 3:01:56.0597128 PM java.exe 6024 QueryBasicInformationFile Z:\Work\Lib\LibUtil.gradle\1.11\taskArtifacts\cache.properties.lock SUCCESS CreationTime: 3/24/2014 2:39:33 PM, LastAccessTime: 3/24/2014 2:39:33 PM, LastWriteTime: 3/24/2014 3:01:35 PM, ChangeTime: 3/24/2014 3:01:35 PM, FileAttributes: A 3:01:56.0597200 PM java.exe 6024 CloseFile Z:\Work\Lib\LibUtil.gradle\1.11\taskArtifacts\cache.properties.lock SUCCESS

3:01:56.0598440 PM java.exe 6024 CreateFile Z:\Work\Lib\LibUtil.gradle\1.11\taskArtifacts\cache.properties.lock SUCCESS Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: n/a, OpenResult: Opened 3:01:56.0598809 PM java.exe 6024 ReadFile Z:\Work\Lib\LibUtil.gradle\1.11\taskArtifacts\cache.properties.lock FILE LOCK CONFLICT Offset: 0, Length: 4,096, Priority: Normal 3:01:56.0599783 PM java.exe 6024 CloseFile Z:\Work\Lib\LibUtil.gradle\1.11\taskArtifacts\cache.properties.lock SUCCESS

2

Looking at this closer, the hash scan starts at:

Z:\Work\Lib

Because I included it as an include path:

includes.from(“Z:\Work\Lib\”)

It then scans for and attempts to hash every file in the “Z:\Work\Lib” path and their children. One potential solution would be to not scan into the “.gradle” folders. It seems to scan more than cpp and H files too. I see it scanning .o files as well.

3

Can you post a bit more detail about what you’re doing? Are you using the native support from Gradle?

You could post some snippets inside HTML ‘code’ tags.

4

I’m attempting to use Gradle in parallel with Visual studio so, I can build the same code for android, Linux and Windows. So yes, native support for Gradle.

Z:\Work\Lib - Where my 50 or so libs reside.

Z:\Work\Projects - where my executable projects are.

I was trying to use Gradle by converting each of my library projects into the format that Gradle likes. Then modifying my VC projects to match.

Z:\Work\Lib\LibCompression for example is one library project.

Z:\Work\Lib\LibCompression\cpp Z:\Work\Lib\LibCompression\headers

Is where I stuck the code and headers. I wasn’t planning on moving my headers out of the projects into a common include folder. I had a build.gradle file in LibCompression folder. In this file, I had the header search path set to

includes.from(“Z:\Work\Lib”)

Essentially my include path was one level above the libcompression project path. Because each of my projects would include a different project’s headers with

#include <LibUtil/headers/LibUtil.h>

So, the Z:\Work\Lib include path would let the include be resolved.

The issue is that Gradle tries to generate hashes for the include folders defined in the build.gradle but, because I had the include path set to the root of all of my libraries. It tried to generate hashes for all the library projects below the root path. That in itself while slow, didn’t cause any errors. What caused errors is that the hasher went into the “.gradle” folders inside my projects and tried to hash the files that were being written to by the hasher. That’s when you get a file lock error.

I’ve worked around the problem now by, re-creating all of my libraries to be more gradle like. The difficult part of this problem is that it didn’t really report what file the lock problem happened on. I had to use Procmon and watch fileio to see which file has the locking issue. That’s when I noticed the hasher was hashing everything below the include path. Gradle seem to assume that the include path will only contain headers when in my case, it included 50 or so complete VC projects.

I think that an easy fix would be to avoid hashing into the .gradle folders that appear when the hasher does its folder traversal and hashing.

I have a work around for this issue now. I know better, what assumptions Gradle makes about folder and project layout and I’m going to try to match them. My projects were setup to be “bottom up” and gradle assumes things are laid out “top down”. I think “top down” will work better for me too, a single build.gradle instead of 50. The documentation just wasn’t real clear about what Gradle wanted. I can still use Gradle and VC in parallel. I just had to re-create my libraries the gradle/java way.

The takeaway is that if you spec an include path that’s a parent of the current project, when the hasher hashes into the project folder you get a file lock error because the hasher tries to hash it’s own hash file.