SHA-1 checksum portion of file path in gradle cache is missing leading zeros

As a testcase (entire ‘build.gradle’ not included), I built something with a dependency on log4j 1.2.12:

dependencies {
   runtime group: 'log4j', name: 'log4j', version: '1.2.12'

Note that while the SHA-1 checksum of this file is ‘057b8740427ee6d7b0b60792751356cad17dc0d9’ (40 characters, with leading zero), the directory that the file is placed in the cache is ‘57b8740427ee6d7b0b60792751356cad17dc0d9’ (39 characters, without leading zero):

$ sha1sum /opt/gradle/rich/.gradle/caches/modules-2/files-2.1/log4j/log4j/1.2.12/57b8740427ee6d7b0b60792751356cad17dc0d9/log4j-1.2.12.jar

I’m doing something with higher level custom tools that manage dependencies across hundreds of projects that assumes that that portion of the filename is the full 40 character hash, and this breaks that.

I know, a reasonable rebuttal to that is that this is an internal implementation detail, and it’s not part of any documented API, and that the storage on the filesystem could change at any time, and that I simply shouldn’t be doing that.

Nevertheless, I suspect that it is an oversight that the leading zero is lost in this case, and it would likely be a very trivial fix to add it. Compare to GRADLE-2456, in which the leading zero had been lost when publishing an artifact to Artifactory (observed in 1.1, fixed in 1.3-rc-1).

I first observed this in gradle 1.7, but I just tested it with the newly released gradle 2.1 (which is what is shown above), and it is still present.

Hey Rich,
The file path in the gradle cache is not public api. That means it could change with every release. The fact that the sha1 checksum is part of the path is more or less an implementation detail. We are aware of the missing zeros. One reason to ignore these is the file path length limitation on windows we often see. Saving any character here can make a difference. Your best bet is to add the leading zeros yourself.