8193072: File.delete() should remove its path from DeleteOnExitHook.files

[Brian Burkhalter]

Peter / Sean,

Thanks for the comments.

> On Jul 10, 2019, at 5:36 AM, Peter Levart <peter.levart at gmail.com> wrote:
> 
> There are various interleavings of threads that could cause the file to be left undeleted when VM exits.
> 
> To cover concurrent scenarios such as above, the code could use reference counting. Like in the following patch:
> 
> http://cr.openjdk.java.net/~plevart/jdk-dev/8193072_File.undoDeleteOnExit/webrev.01/ <http://cr.openjdk.java.net/~plevart/jdk-dev/8193072_File.undoDeleteOnExit/webrev.01/>
This looks good to me modulo adding this
        SecurityManager security = System.getSecurityManager();
        if (security != null) {
            security.checkDelete(path);
        }
to cancelDeleteOnExit() as suggested below.

> On Jul 10, 2019, at 7:51 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> On 7/9/19 7:40 PM, Brian Burkhalter wrote:
>> I don’t know. On the one hand this does not take an action like reading, writing, or deleting, but on the other it could end up causing files to be left lying around after VM termination which were expected to be deleted. I suppose that could be considered to be some sort of security issue.
> 
> Yes I think so.
> 
> I would probably just use the same permission (FilePermission(file,"delete")). If you have been granted permission to delete a file, then you should have permission to cancel that deletion as well.

That’s a  good idea.

Thanks,

Brian