Vlad Chesnokov

Thanks for the research! I think it justifies the feature quite well. Implementation-wise, Gradle does not have an embedded DB, and it's unlikely that we want to have one. A...

@DevDengChao We should not rely on that OS-specific behavior. And there is a relevant open issue that is planned to be addressed: * https://github.com/gradle/gradle/issues/15367

This sounds promising. I think you can re-use that logic from the wrapper code.

For temp file logic, take a look at `org.gradle.wrapper.Install#forceFetch`, `org.gradle.caching.local.internal.DefaultBuildCacheTempFileStore`, and `org.gradle.jvm.toolchain.internal.install.SecureFileDownloader#downloadResource` For changing the code, you can start from `org.gradle.api.internal.artifacts.repositories.DefaultMavenArtifactRepository` and `org.gradle.internal.resource.transport.http.HttpConnectorFactory`

Thank you for your contribution! This PR has a valid DCO and tests. The relevant team for this area will confirm the design of the implementation choices.

The issue is in the backlog of the relevant team and is prioritized by them.

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. *** Indeed, in...

Sorry for the late reply. This issue needs a decision from the team responsible for that area. They have been informed. Response time may vary. *** Another workaround is to...

This issue needs a decision from the team responsible for that area. They have been informed. Response time may vary. *** Since this is a runtime concern, we might want...

While PR looks good, we probably want to make a more drastic redesign/deprecation of Copy task in favor of DSL approaches in 9.0. cc @lptr