zipTree does not clean up the build/tmp/.cache/expanded directory #31881
Labels
a:bug
has:workaround
Indicates that the issue has a workaround
in:file-tasks
copy sync zip tar rename delete
Comments
goodwinnk
pushed a commit
to JetBrains/kotlin
that referenced
this issue
Dec 25, 2024
Acts as workaround for gradle/gradle#31881 ^KT-74143 Fixed
goodwinnk
pushed a commit
to JetBrains/kotlin
that referenced
this issue
Dec 25, 2024
…tStream Acts as a workaround for gradle/gradle#31881, preventing a physical copy of expanded archive to exist ^KT-74143 Fixed
goodwinnk
pushed a commit
to JetBrains/kotlin
that referenced
this issue
Dec 25, 2024
…tStream Acts as a workaround for gradle/gradle#31881, preventing a physical copy of expanded archive to exist ^KT-74143 Fixed
ljacomet
added
in:file-tasks
|
The issue is in the backlog of the relevant team, but the existence of a workaround means it might take a while before a fix is made. As indicated, running |
KotlinBuild
pushed a commit
to JetBrains/kotlin
that referenced
this issue
Jan 9, 2025
…tStream Acts as a workaround for gradle/gradle#31881, preventing a physical copy of expanded archive to exist ^KT-74143 Fixed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Current Behavior
Usage of files accessible via
ArchiveOperations.zipTreeleads to unpacking them to a temporary directory likebuild/tmp/.cache/expanded/zip_%hash%. That's fine.However, the observable behavior is that the directory is never cleaned up unless tasks like
cleanare called explicitly or the files are removed manually.Expected Behavior
The temporary expanded directory should be either cleaned up after work with the zip tree is finished or there should be some regular cleanup routine.
Another solution is to document this behavior and mention that it's user's responsibility to remove the temporary directory. Is there even a reliable way to know the temporary directory path related to a specific zip file tree?
Context (optional)
As a reference, in Kotlin we are using
zipTreefor repackaging jar files. Currently, the directory is taking 21 GB by 272 different expanded archives on my machine.Self-contained Reproducer Project
https://github.com/ALikhachev/gradle-reproducers/tree/main/zipTree-does-not-clean-up
Gradle version
8.12
Build scan URL (optional)
No response
Your Environment (optional)
No response
The text was updated successfully, but these errors were encountered: