RFR JDK-8174996: jar leaves temporary file when exception occur in creating jar

[Xueming Shen]

On 2/16/17 4:54 PM, Paul Sandoz wrote:
>
> Can you use File.deleteOnExit instead of explicitly deleting?

Hi Paul,

What's the benefit of delaying the delete till vm exists?

Another considerable alternative is to 
Files.deleteIfExists(tmpFile.toPath) with the benefit
of throwing another IOException (to indicate the failure of deletion).

Sherman

>
>> On 16 Feb 2017, at 12:09, Xueming Shen <xueming.shen at oracle.com> wrote:
>>
>> Hi,
>>
>> Please help review the change for
>>
>> issue: https://bugs.openjdk.java.net/browse/JDK-8174996
>> webrev: http://cr.openjdk.java.net/~sherman/8174996/webrev
>>
>> The cause/trigger of this "regression" is that the jdk9 jar implementation now builds
>> the target jar file on a temporary file first  and then copies it to the the target
>> destination, after sanity check if any. Same as what the "update" operation has been
>> implemented (which means this is A problem for "update" operation as well, if
>> ZipException/IOException gets thrown in the middle of the operation the temporary
>> file is left un-deleted. In case of "update" operation, the temp file is at the same
>> directory as the existing target jar file, if the "jar" is not from the stdin).
>>
>> In fact, in releases before jdk9, even there is no temporary file left behind in this
>> situation, the destination jar file is left as a "broken jar" without being deleted. So
>> for the use scenario described in this issue report, with jdk 8 or earlier, command
>>
>> jar cf test.jar -C a test test
>>
>> will create a broken jar file "test.jar", after the exception thrown.
>>
>> So strictly speaking, this is a not really a "regression", but a bug in different
>> form, though it is still desired to be addressed/fixed. Given the nature the temporary
>> file, it is relatively hard to create a regression test to check/verify the remove
>> of the temporary after the exception. I'm not adding an auto regression test
>> for this fix, though the fix has been verified manually.
>>
>>
>> Thanks,
>> Sherman
>>