LocalFileSystem-based file tests are flaky about file.dart HOT 2 OPEN

I've been trying to fix some other test flakiness (which might address that ENOENT error) and have been running hundreds of test iterations, and I've also been hitting failures related to access timestamps:

00:03 +13 ~2: loading test/local_test.dart
  Expected: a DateTime <= 2020-06-19 11:09:37.999
    Actual: DateTime:<2020-06-19 11:09:38.000>
     Which: is after 2020-06-19 11:09:37.999 by 0:00:00.001000

  package:test_api                expect
  test/common_tests.dart 1597:11  runCommonTests.<fn>.<fn>.<fn>.<fn>

00:03 +13 ~2: loading test/local_test.dart
  Expected: a DateTime <= 2020-06-19 11:44:49.997
    Actual: DateTime:<2020-06-19 11:44:50.000>
     Which: is after 2020-06-19 11:44:49.997 by 0:00:00.003000
  
  package:test_api                expect
  test/common_tests.dart 1661:11  runCommonTests.<fn>.<fn>.<fn>.<fn>

00:05 +549 ~4 -1: ChrootFileSystem localBacked common File lastModified isNowForNewlyCreatedFile [E]
  Expected: a DateTime <= 2020-06-19 11:58:33.000
    Actual: DateTime:<2020-06-19 11:58:34.000>
     Which: is after 2020-06-19 11:58:33.000 by 0:00:01.000000

  package:test_api                expect
  test/common_tests.dart 1638:11  runCommonTests.<fn>.<fn>.<fn>.<fn>

In all of the cases, the "Actual" value seems to be at an exact second, which probably isn't coincidental.

I don't see anything obviously wrong with the test code and so far haven't been able to successfully simulate the failure. (As an aside, ceil([DateTime]) is misleading since it's not a mathematical ceiling, but I think it does behave as intended. I think it'd be clearer to replace ceil() with floor() + oneSecond though.)

from file.dart.

I believe the ENOENT errors should be fixed by #150.

In all of the cases, the "Actual" value seems to be at an exact second, which probably isn't coincidental.

This is a red herring. I misread the test. Those "Actual" times are the ones rounded down by floor(), so it's expected that they are at an exact second. The "Expected" time is the file's access time. (That's confusing; we should change those expect() calls since it's the access time that is being tested.)

Anyway, I made a reproduction case by distilling one of the modification time tests down and running it in a continuous loop for 1 second. (The modification time tests can hit a similar failure as the access time ones, and with modification times I don't need to worry about potential weirdness from noatime or relatime settings.) The failure also happens when using dart:io's File directly, and so far I've been unable to reproduce it with an analogous C program, so I think that the timestamp discrepancy is from some weirdness in the SDK or in the VM. I'll file an SDK bug.

from file.dart.