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

Hi Brian, On 7/26/19 12:42 AM, Brian Burkhalter wrote: On Jul 11, 2019, at 12:52 AM, Peter Levart > wrote: On 7/11/19 9:47 AM, Peter Levart wrote: http://cr.openjdk.java.net/~plevart/jdk-dev/8193072_File.undoDeleteOnExit/webrev.02/ Another thing to

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

> On Jul 25, 2019, at 3:42 PM, Brian Burkhalter > wrote: > > the deletion order is (I think) file1, file2, file3 which is the reverse of > the order of initial registration. I intended *not* the reverse order of initial registration. Brian

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

> On Jul 11, 2019, at 12:52 AM, Peter Levart wrote: > > On 7/11/19 9:47 AM, Peter Levart wrote: >> >> http://cr.openjdk.java.net/~plevart/jdk-dev/8193072_File.undoDeleteOnExit/webrev.02/ >> >> >> >> >

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

: 8193072: File.delete() should remove its path from DeleteOnExitHook.files On 7/10/19 5:17 PM, Brian Burkhalter wrote: > I incorporated Peter’s version, adding the security check in > cancelDeleteOnExit(), tweaking its verbiage along with that of > deleteOnExit(), and modified the test Del

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

On 7/11/19 9:47 AM, Peter Levart wrote: http://cr.openjdk.java.net/~plevart/jdk-dev/8193072_File.undoDeleteOnExit/webrev.02/ Another thing to consider (done in above webrev.02) is what to do with unbalanced cancelDeleteOnExit(). I think it is better to throw exception than to

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

Hi, On 7/11/19 3:51 AM, Ivan Gerasimov wrote: On 7/10/19 5:17 PM, Brian Burkhalter wrote: I incorporated Peter’s version, adding the security check in cancelDeleteOnExit(), tweaking its verbiage along with that of deleteOnExit(), and modified the test DeleteOnExit to verify the new method.

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

On 7/10/19 5:17 PM, Brian Burkhalter wrote: I incorporated Peter’s version, adding the security check in cancelDeleteOnExit(), tweaking its verbiage along with that of deleteOnExit(), and modified the test DeleteOnExit to verify the new method. The updated version is here:

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

I incorporated Peter’s version, adding the security check in cancelDeleteOnExit(), tweaking its verbiage along with that of deleteOnExit(), and modified the test DeleteOnExit to verify the new method. The updated version is here: http://cr.openjdk.java.net/~bpb/8193072/webrev.03/

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

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

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

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

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

Hi, On 7/9/19 8:08 PM, Brian Burkhalter wrote: On Jul 9, 2019, at 8:31 AM, Brian Burkhalter wrote: Since deleteOnExit() is an deliberate act, perhaps there should be a corresponding withdrawDeleteOnExit() that reverses it so that it is intentional and not a side-effect of other File

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

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.

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

: 8193072: File.delete() should remove its path from DeleteOnExitHook.files > On Jul 9, 2019, at 8:31 AM, Brian Burkhalter > wrote: > >> Since deleteOnExit() is an deliberate act, perhaps there should be a >> corresponding withdrawDeleteOnExit() that reverses it so that

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

Cc: core-libs-dev@openjdk.java.net Subject: Re: 8193072: File.delete() should remove its path from DeleteOnExitHook.files Hi Roger, You might be correct but I wrote up a different version at the end of yesterday. Not sure it is right but I might as well post it: http://cr.openjdk.java.net/~bpb

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

> On Jul 9, 2019, at 8:31 AM, Brian Burkhalter > wrote: > >> Since deleteOnExit() is an deliberate act, perhaps there should be a >> corresponding withdrawDeleteOnExit() that reverses it so that it is >> intentional and not a side-effect of other File methods. > > I think this is a better

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

Hi Roger, > On Jul 9, 2019, at 8:25 AM, Roger Riggs wrote: > > The interesting part will be writing/updating the specification to make it > clear what happens and under what conditions. > How often are File instances re-used vs creating new ones. > And any interactions with other APIs that

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

Hi Brian, The interesting part will be writing/updating the specification to make it clear what happens and under what conditions. How often are File instances re-used vs creating new ones. And any interactions with other APIs that create or delete files with the same name.  (file channels,

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

Hi Roger, You might be correct but I wrote up a different version at the end of yesterday. Not sure it is right but I might as well post it: http://cr.openjdk.java.net/~bpb/8193072/webrev.01/ Thanks, Brian > On Jul 9, 2019, at 7:34 AM, Roger Riggs wrote: > > The sequence described is the

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

Hi Brian, The sequence described is the specified behavior of the API, whether it is a developer mistake or not is unknowable but it would be a compatibility issue to change it. The filename is the key and there is no way to determine if it is the original file or a replacement. deleteOnExit

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

Ivan / Jason, Thanks for the good observations. > On Jul 8, 2019, at 1:35 PM, Ivan Gerasimov wrote: > > I believe this would introduce a behavior change in a scenario lile: > File f = ...; > f.deleteOnExit(); > f.delete(); > f.createNewFile(); > > I.e. when the with the same name is

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

From: core-libs-dev on behalf of Brian Burkhalter Sent: Monday, July 8, 2019 3:11 PM To: core-libs-dev Subject: 8193072: File.delete() should remove its path from DeleteOnExitHook.files https://bugs.openjdk.java.net/browse/JDK-8193072 <https://bugs.openjdk.java.net/bro

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

Hi Brian! I believe this would introduce a behavior change in a scenario lile: File f = ...; f.deleteOnExit(); f.delete(); f.createNewFile(); I.e. when the with the same name is recreated.  Current behavior is to unlink such a file before exiting, no matter if it were explicitly deleted and

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

Looks OK brian and does not seem to require any update to runHooks() so all good for me :-) > On Jul 8, 2019, at 4:11 PM, Brian Burkhalter > wrote: > > https://bugs.openjdk.java.net/browse/JDK-8193072 > > > There does appear to be a memory

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

https://bugs.openjdk.java.net/browse/JDK-8193072 There does appear to be a memory leak of sorts if one does something like — File[] files; for (int i = 0; i < largeNumber; i++) { files[i] = File.createTempFile(“blah”, null);