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 <[email protected]> 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
