RFR: 8147588: Jar file and Zip file not removed in spite of the OPEN_DELETE flag

[Alan Bateman]

On 12/05/2016 20:16, Xueming Shen wrote:
> Hi,
>
> Please help review the proposed change for #8147588
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8147588
> webrev: http://cr.openjdk.java.net/~sherman/8147588/webrev
>
> This is a regression on Windows platform triggered by the change for
> https://bugs.openjdk.java.net/browse/JDK-8145260, in which we brought
> the ZipFile native natively code to java for better performance (both
> memory and access).
>
> As showed the from ln#107-114 at webrev below
> http://cr.openjdk.java.net/~sherman/8145260/webrev.push/src/java.base/share/native/libzip/ZipFile.c-.html 
>
>
> The original native implementation uses a special "Windows-only"
> option O_TEMPORARY to open the zip/jar file on Windows to support
> this OPEN_DELETE functionality.
>
> There is no corresponding public open/delete functionality at java.io
> API right now. The proposed the change here is to add a private
> constructor for RandomAccessFile and access from ZipFile via
> SharedSecrets. This O_TEMPORARY is only supported on Windows
> platform.
I assume O_TEMPORARY maps to Windows FILE_FLAG_DELETE_ON_CLOSE flag. In 
the new file system API then this gets exposed as the DELETE_ON_CLOSE 
open option but it isn't exposed via RAF. I assume it would be too much 
of a change to move ZipFile, particularly with behavior changes related 
to interruption.

I've looked through the patch but I just wondering if there are cleaner 
alternatives. What would you think about not pushing O_TEMPORARY to RAF 
but instead have ZipFile open the zip file with ZFILE_Open, wrap it with 
a FileDescriptor and then create a RAF to that FileDescriptor. I realize 
RAF doesn't have a public constructor for this so it needs plumbing but 
the nice this is that it keeps this specific mode issue out of RAF.

-Alan