`e2e::directories::dep_on_current_directory` spontaneous failure

[GrigorenkoPV]

Got this spontaneous failure, cannot reproduce:

---- e2e::directories::dep_on_current_directory stdout ----

thread 'e2e::directories::dep_on_current_directory' panicked at tests/e2e/directories.rs:21:5:
assertion `left == right` failed
  left: [98, 117, 105, 108, 100, 46, 110, 105, 110, 106, 97, 10, 102, 111, 111, 10, 111, 117, 116, 10]
 right: [98, 117, 105, 108, 100, 46, 110, 105, 110, 106, 97, 10, 102, 111, 111, 10, 102, 111, 111, 50, 10, 111, 117, 116, 10]
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

The bytes are, correspondingly,

b"build.ninja\nfoo\nout\n"

and

b"build.ninja\nfoo\nfoo2\nout\n"

The code in question: https://github.com/evmar/n2/blob/bea43cde58a4057a3f9db4813418f2ef8bfee107/tests/e2e/directories.rs#L3-L21

Maybe a race condition between tests or a buffer did not get flushed?

[evmar]

That does look like a race, hmm. The test runner runs the e2e tests in parallel threads, but they each spawn a separate n2 process so there should be no buffering-related issues.

But the threads do each create their own temp dir. Those appear to use a thread-local random number generator... is it possible each thread has the same seed? I would expect more races in that case.

[evmar]

Oh wait, looking at the test, more likely it just didn't notice the directory changed. I will fix it.

[evmar]

I am sorta not sure what is going on here, because if the test usually passes that means we do see directory modifications.

It looks like stat has high resolution on Linux: https://github.com/rust-lang/rust/blob/3736b85779d1db4c215b910004d7efcd7aff8408/library/std/src/sys/pal/unix/fs.rs#L488

[GrigorenkoPV]

but they each spawn a separate n2 process so there should be no buffering-related issues.

I mean flushing the file contents to disk after TestSpace::write, but it seems to be using std::fs::write under the hood, so probably that's not the case.