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

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Xueming Shen
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

Reply | Threaded
Open this post in threaded view
|

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

Paul Sandoz
Hi Sherman,

Can you use File.deleteOnExit instead of explicitly deleting?

Paul.

> On 16 Feb 2017, at 12:09, Xueming Shen <[hidden email]> 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
>

Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
>>