JDK 9 RFR of 8160220: (fs) Tests in jdk/test/java/nio/file/WatchService leave directory trees behind

[Brian Burkhalter]

On Jul 13, 2016, at 8:03 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote:

> On 13/07/16 15:57, Brian Burkhalter wrote:
>> 
>> On Jul 12, 2016, at 10:36 PM, Alan Bateman <Alan.Bateman at oracle.com
>> <mailto:Alan.Bateman at oracle.com>> wrote:
>> 
>>> On 12/07/2016 21:36, Brian Burkhalter wrote:
>>>> :
>>>> Here’s an updated version which uses
>>>> FileUtils.deleteFileTreeWithRetry() and does not use deleteOnExit():
>>>> 
>>>> http://cr.openjdk.java.net/~bpb/8160220/webrev.01/
>>>> 
>>> Thinking about, this isn't needed. Since you've moved to the work
>>> directory then jtreg will do the clean-up (including retry). So the
>>> change should be to just move from /tmp to the work directory and you
>>> should be all set.
>> 
>> So I should be able to remove FileUtils.deleteFileTreeWithRetry() and
>> the jdk.testlibrary references in *both* of these tests as well as the
>> original deleteFileTree() in DeleteInterference.
> 
> If the tests are using the current working directory, then yes jtreg
> will clean up afterwards.  The only reason to retain the explicit
> delete is if you intend to run the tests manually ( outside of jtreg ),
> then of course it will need to remove the files itself ( so as to not
> clutter up your directory ). Either way should be fine, just ensure,
> if you intend to delete the files explicitly, that there are enough
> bread crumbs left in the working directory if the test fails ( so
> you can duplicate/debug the issue ).

This rather sounds as if the tests should use the current working directly and only do an explicit delete if the test fails outside of jtreg, e.g., the test.src property is undefined. If that is the conclusion then I don’t believe we have consistency among the tests at this time on this point.

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20160713/baf222fb/attachment-0001.html>