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 > > >
