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

[Brian Burkhalter]

> On Jul 11, 2019, at 12:52 AM, Peter Levart <peter.levart at gmail.com> wrote:
> 
> On 7/11/19 9:47 AM, Peter Levart wrote:
>> 
>> http://cr.openjdk.java.net/~plevart/jdk-dev/8193072_File.undoDeleteOnExit/webrev.02/ <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 silently ignore it. This way unintentional bugs can be uncovered which would otherwise just cause erratic behavior.

The above patch looks pretty good but unless I am not comprehending the code I think there may still be behavioral incompatibilities which might not be acceptable. For example, for the existing code base with the following sequence of operations

File file1, file2, file3;

file1.deleteOnExit();
file2.deleteOnExit();
file3.deleteOnExit();

the deletion order is file3, file2, file1. For the proposed patch with the following sequence of operations

file1.deleteOnExit();
file2.deleteOnExit();
file3.deleteOnExit();
file1.cancelDeleteOnExit(); // file1 is removed from the map
file2.cancelDeleteOnExit(); // file2 is removed from the map
file2.createNewFIle();
file2.deleteOnExit(); // file2 is added back into the map
file1.createNewFIle();
file1.deleteOnExit(); // file1 is added back into the map

the deletion order is (I think) file1, file2, file3 which is the reverse of the order of initial registration. Of course it is conceivable to change the specification but that seems dangerous somehow. Also for the patch above for this sequence of operations

file1.deleteOnExit();
file2.deleteOnExit();
file3.deleteOnExit();
file1.cancelDeleteOnExit(); // file1 is removed from the map
file2.cancelDeleteOnExit(); // file2 is removed from the map
file2.createNewFIle();
file1.createNewFIle();

then file3 is deleted on exit but file1 and file2 are not which differs from current behavior.

As Roger wrote

> On Jul 9, 2019, at 7:34 AM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
> 
> The filename is the key and there is no way to determine if it is the original file or a replacement. deleteOnExit Wins!

the filename is the key and if we toss the key then we lose the order of registration. Given this I am not sure any more that it is possible to fix this issue without introducing an incompatible behavioral change.

Thanks,

Brian