OK. I found the problem. It was indeed a problem with the test. Java doesn’t
close Streams automatically.
Ralph
> On Feb 19, 2020, at 5:19 PM, Ralph Goers wrote:
>
> OK. This is even crazier. I commented out all the calls to Log4j in the code.
> So all the test does is create a directory, cop
OK. This is even crazier. I commented out all the calls to Log4j in the code.
So all the test does is create a directory, copy a file into the directory,
read the file, and then delete the file. That has the same behavior. The delete
says it worked but the file is still in the directory when I l
I have modified this test so that it now does something reasonable, and yet it
still fails trying to delete the directory the logs are written to after the
test has completed. I do not understand why. I have verified that Files.delete
and Files.exist both say the files have been deleted yet when
> On Feb 17, 2020, at 10:42 PM, Ralph Goers wrote:
>
> This test is failing on Windows. I have been debugging it for the last 6
> hours. It is failing because it is trying to create the test log directory
> and Windows says it isn’t empty. The thing is, Files.delete has been called
> agains
This test is failing on Windows. I have been debugging it for the last 6 hours.
It is failing because it is trying to create the test log directory and Windows
says it isn’t empty. The thing is, Files.delete has been called against all the
files in the directory without error. I put a breakpoint
