That sounds like a file modification time granularity issue. Does Windows not support milliseconds or finer for file modification times? It could be that the test executed too fast!
On Fri, Aug 7, 2020 at 09:01 Gary Gregory <garydgreg...@gmail.com> wrote: > As of recently, I am seing: > > [INFO] Running org.apache.commons.io.FileUtilsTestCase > [ERROR] Tests run: 142, Failures: 2, Errors: 0, Skipped: 1, Time elapsed: > 5.613 s <<< FAILURE! - in org.apache.commons.io.FileUtilsTestCase > [ERROR] testCopyFile2WithoutFileDatePreservation Time elapsed: 0.038 s > <<< FAILURE! > org.opentest4j.AssertionFailedError: Check last modified date not same as > input ==> expected: not equal but was: <1596807101505> > at > org.apache.commons.io > .FileUtilsTestCase.testCopyFile2WithoutFileDatePreservation(FileUtilsTestCase.java:1229) > > [ERROR] testCopyDirectoryPreserveDates Time elapsed: 0.027 s <<< FAILURE! > org.opentest4j.AssertionFailedError: expected: <true> but was: <false> > at > org.apache.commons.io > .FileUtilsTestCase.testCopyDirectoryPreserveDates(FileUtilsTestCase.java:1403) > > I am wondering if GitHub/Travis can also be set up to run at least one > build on Windows so we can catch issues like these? > > Gary > -- Matt Sicker <boa...@gmail.com>
