gradle
Clean up temporary files created via TempFiles
Starting with Gradle 6.x JavaExec tasks automatically generate file %TEMP%/gradle-javaexec-classpathXXX.jar when classpath larger then Windows path limit:
- https://github.com/gradle/gradle/issues/10114 - Mitigate long classpath on Windows for JavaExec
- https://docs.gradle.org/6.0/release-notes.html - section Automatic shortening of long command-lines for Java applications on Windows
I removed our custom code (that prepared pathing JAR) and checked it continues to work in Gradle 6.6.1.
Execution of task gradle bootRun (which is derived from JavaExec) naturally creates file %TEMP%/gradle-javaexec-classpathXXX.jar. Using procexp utility I see that app starts exactly with this JAR as -cp parameter.
I run Gradle in mintty + from cmd.
In both cases termination (Ctrl+C) of JavaExec task leaves file %TMP%/gradle-javaexec-classpathXXX.jar behind.
Process dependencies shows that GradleDaemon waits for app to finish.
I see that Gradle worker waits for JavaExec task to finish. I believe thi worker can cleanup pathing JAR after child termination.
WORKAROUD Recent Windows 10 introduced Storage Sense: https://techcommunity.microsoft.com/t5/storage-at-microsoft/windows-10-and-storage-sense/ba-p/428270
Earlier we have SilentCleanup task:
schtasks /query /FO list /V /TN \Microsoft\Windows\DiskCleanup\SilentCleanup
In any case both solutions run:
%windir%\system32\cleanmgr.exe /autoclean /d %systemdrive%
and:
reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VolumeCaches\Temporary Files"
FileList: *.*
Folder: %TEMP%|%WINDIR%\Temp|%WINDIR%\Logs|%WINDIR%\System32\LogFiles
The limit is mtime 7 days, more or less official, my experiments supports that period and similar working in official docs:
https://docs.microsoft.com/en-us/troubleshoot/windows-server/backup-and-storage/automating-disk-cleanup-tool Temporary Files - Programs sometimes store temporary information in a Temp folder. Before a program quits, it usually deletes this information. You can safely delete temporary files that have not been modified in over a week.
So as long Gradle generate files under %TEMP% Windows built-in tools remove garbage. But Gradle might do that itself...
Sorry for the late reply.
The issue is in the backlog of the relevant team and is prioritized by them.
The originates from TempFiles implementation.
The assumption here is that OS manages temporary files.
~~However, it should be no harm to add .deleteOnExit().~~
Relevant context:
- https://superuser.com/questions/296824/when-is-a-windows-users-temp-directory-cleaned-out
FWIW, this problem got 1000X worse due to #15654
Because GradleUserHomeTemporaryFileProvider now hardcodes the usage of FileUtils.canonicalize(new File(gradleUserHomeDirProvider.getGradleUserHomeDirectory(), ".tmp")); any OS level cleanup of temp files that could have helped before (assuming the user had java.io.tmpdir configured in a sane way) is now useless.
Now if gradle doesn't reliably clean up every temp file it creates, nothing ever will.
Yup, just had a test suite break this morning due to a server running out of disk space, and it looks like https://github.com/gradle/gradle/pull/15654 was ultimately the culprit.
In the past, I hacked around this tmp file leak problem by introducing a custom gradle task which searched java.io.tmpdir for the classpath files leaked by Gradle and auto-deleted ones that were more than a couple days old. However, https://github.com/gradle/gradle/pull/15654 moved those files to a new location and it seems that Gradle still makes no attempt to clean up after itself, so once again multiple GBs worth of leaked gradle classpath files are accumulating on all of our servers and dev workstations.
I suppose I'll update my custom cleanup task to search to new location as well, but it'd be great if this file leak could be fixed within Gradle itself so devs don't have to develop their own workarounds and tmp file cleanup logic.
