Peter / Sean, Thanks for the comments.
> On Jul 10, 2019, at 5:36 AM, Peter Levart <peter.lev...@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.mul...@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
