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 <ralph.go...@dslextreme.com> 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, 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 look > there and the directory delete still fails saying it isn’t empty. > > So something in the test itself must be causing this. > > Ralph > >> On Feb 19, 2020, at 4:57 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: >> >> 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 I >> try to delete the directory it fails because it isn’t empty. And when I put >> a breakpoint there and look at the directory I still see the files. >> >> All this implies that the file handles are still in use by something but I >> have no idea what it could be. Any ideas? >> >> The implication of this test is that files are not being released when log4j >> rolls the files or shuts down, so Windows users would experience problems. >> >> Ralph >> >>> On Feb 17, 2020, at 10:59 PM, Ralph Goers <ralph.go...@dslextreme.com> >>> wrote: >>> >>> >>> >>>> On Feb 17, 2020, at 10:42 PM, Ralph Goers <ralph.go...@dslextreme.com> >>>> 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 against all the files in the directory without error. I put a >>>> breakpoint when it tries to delete the folder and I can still see the file >>>> in the directory even though delete worked. I have also verified that the >>>> RollingFileManager closed the OutputStream. After the program terminates >>>> the file disappears but the directory is still there. >>>> >>>> Have I said before how much I hate Windows? >>>> >>>> Anyone have any idea why the file handle is not being released? >>>> >>> >>> Actually, this whole test doesn’t make any sense. I don’t know what I was >>> thinking when I created it. It will never trigger the >>> OnStartupTriggeringPolicy since it uses a static variable to track the JVM >>> start time. >>> >>> Ralph >>> >>> >>> >> >> >> > > >
