rm::test_rm_rm3 test fails

[jgarzik]

rm::test_rm_rm3 test fails at line 868 of tree/tests/rm/mod.rs:

    let test_dir = &format!("{}/test_rm_rm3", env!("CARGO_TARGET_TMPDIR"));
...
    fs::create_dir(test_dir).unwrap();   // <<--- this fails

Manually removing the ./target/tmp directory causes the test to succeed:

thread 'rm::test_rm_rm3' panicked at tree/tests/rm/mod.rs:868:30:
called `Result::unwrap()` on an `Err` value: Os { code: 17, kind: AlreadyExists, message: "File exists" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
test rm::test_rm_rm3 ... FAILED

failures:

failures:
    rm::test_rm_rm3

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 96 filtered out; finished in 0.00s

error: test failed, to rerun pass `-p posixutils-tree --test integration`
% vi +868 tree/tests/rm/mod.rs 
% find . -name test_rm_rm3
./target/tmp/test_rm_rm3
% rm -rf target/tmp/*
% GETTEXT_SYSTEM=1 GETTEXT_DIR=/usr/local cargo test -p posixutils-tree --test integration rm::test_rm_rm3 -- --nocapture
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.07s
     Running tests/integration.rs (target/debug/deps/integration-1e07fe9a2d399161)

running 1 test
test rm::test_rm_rm3 ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 96 filtered out; finished in 0.02s

[JRF63]

It should already be automatically deleting the test directory at the end of the test.

[jgarzik]

It should already be automatically deleting the test directory at the end of the test.

This is why tests frequently have the pattern:

1. Clean up
2. Run test
3. Clean up (again)

The first step is to ensure no previous failed testing run pollutes the current test.

Further testing indicates:

1. cargo clean followed by cargo test -p posixutils-tree --test integration rm::test_rm_rm3 -- --nocapture and the test works. i.e. When no other test has been run.
2. Full cargo test does not work.

Based on this, I guess that other tests may be interfering with this test?

[jgarzik]

Linux testing on Ubuntu 22 LTS indicates that this issue is present on Linux also.

[JRF63]

I figured out what's happening here. It's the umask multi-threading race hazard from #102 again.

[jgarzik]

Fixed by #115