JCgH4164838Gh792C124B5 commented on issue #271: Proposed fix for LOG4J2-2610 rollover issue: URL: https://github.com/apache/logging-log4j2/pull/271#issuecomment-498046100 Hello @rgoers (**apologies in advance for the long response**). The **short answer** is _none of the existing test cases actually failed_ due to filesystem tunneling behaviour (was only noted by "manual observation" with the necessary preconditions). `RollingAppenderSizeWithTimeTest.testAppender()` was the only test that was actually failing (which as per discussion above with @carterkozak _actually appears to be a separate issue_ - where the 1ms sleep in `RollingFileManager.createFileAfterRollover()` was needed to get the test to succeed). When debugging an application that used Log4j2 with a "size-and-time" rollover strategy, I noted that when the _current log file_ had a _`creationTime` > 24hrs older than the current date/time_, the rollover behaved strangely. When the current log file was rolled over the new "xxxx.log" would "_carry over_" the same >24hrs old `creationTime` as the original file. Then, later, on the next rollover, it's rolled-over name ("xxxx_CCYY-MM-DD_y.log") still had the CCCYY-MM-DD represented by the `creationTime` of the original log file (2 rollovers ago). Basically you need sufficient _"discontiguous time"_ between the creationTime of the original file and the actual current system datetime to observe the behaviour. The amount of time required to observe it depended on the rollover period. Due to the conditions required to reproduce it, I didn't initally consider a test case to try and demonstrate it failing. Instead, I did a manual test set up using `RollingAppenderSizeWithTimeTest`. I either suppressed the directory cleanup "`withCleanFoldersRule`" in the test, or used a breakpoint so I could copy a log file with a "really old" creationTime in place. Using the new code with Files.setAttribute() that you mentioned, I suppose you could create an empty file in the test before the appender tries to access it. Then you could set its creationTime to >24hrs in the past, let the appender roll it over/create the new .log file and then _confirm by reading its creationTime attribute that it is using "today's date" as expected_ ? **Sorry again for the long explanation**, but it really is/was a pain to reproduce in a "nice" way. :sweat_smile:.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
