On Fri, Aug 7, 2020 at 10:04 AM Matt Sicker <boa...@gmail.com> wrote:
> 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! > This might be a classic bug I've run into at work: https://bugs.openjdk.java.net/browse/JDK-8177809 Basically, never use File.lastModified(), use Files.getLastModifiedTime(). Gary > > 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> >
