8193072: File.delete() should remove its path from DeleteOnExitHook.files
Roger Riggs
Roger.Riggs at oracle.com
Tue Jul 9 15:25:56 UTC 2019
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, zip, etc...)
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.
Roger
On 7/9/19 11:07 AM, Brian Burkhalter wrote:
> 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 <Roger.Riggs at oracle.com
>> <mailto:Roger.Riggs at oracle.com>> wrote:
>>
>> 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 Wins!
>
More information about the core-libs-dev
mailing list