JDK-4957695 : URLJarFile.retrieve does not delete tmpFile on IOException
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 1.4.2
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2003-11-20
  • Updated: 2003-12-15
  • Resolved: 2003-12-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
5.0 b32Fixed
Related Reports
Relates :  
Description
URLJarFile.retrieve fails to delete the jar_cache tmpFile if an IOException occurs when reading from the input stream (or when writing to the output stream). This can result in accumulation of unused files in the temp directory, and can lead to unnecessary out-of-disk-space failures.

As an example of this, we have an httpmd: URL type that we use for referring to jar files, which also includes a message digest for the jar file contents. If the contents of the jar file are changed, subsequent attempts to load the jar file through the original httpmd: URL will cause an IOException to be thrown when URLJarFile.retrieve reads the input stream (because the digests don't match). This leaves a file in the temp directory. Depending on the application, there may well be repeated attempts over time to read from that URL, each one adding to the file accumulation. Because the IOException is thrown at the end of reading the entire contents, each file left around contains the complete jar contents, so the sizes can add up over time.

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta FIXED IN: tiger-beta INTEGRATED IN: tiger-b32 tiger-beta
14-06-2004

PUBLIC COMMENTS URLJarFile.retrieve fails to delete the jar_cache tmpFile if an IOException occurs when reading from the input stream (or when writing to the output stream). This can result in accumulation of unused files in the temp directory, and can lead to unnecessary out-of-disk-space failures. As an example of this, we have an httpmd: URL type that we use for referring to jar files, which also includes a message digest for the jar file contents. If the contents of the jar file are changed, subsequent attempts to load the jar file through the original httpmd: URL will cause an IOException to be thrown when URLJarFile.retrieve reads the input stream (because the digests don't match). This leaves a file in the temp directory. Depending on the application, there may well be repeated attempts over time to read from that URL, each one adding to the file accumulation. Because the IOException is thrown at the end of reading the entire contents, each file left around contains the complete jar contents, so the sizes can add up over time.
10-06-2004

EVALUATION Simple solution is to catch the exception and delete the tmpFile. Unfortunately, the regression test for this bug is affected by Nio bug 4960962, so I cannot putback a regression test yet. We will also call deleteOnExit() for these files so they are automatically deleted on VM exit. ###@###.### 2003-11-28
28-11-2003