Ignore NoSuchFileException in @TempDir cleanup

[gilday]

Overview

In TempDirectory's cleanup logic, while walking the temp directory, the file walker may fail to visit a file that has been removed by another thread or process. In this case, JUnit should ignore the NoSuchFileException, because there's nothing to clean up.

I have observed such failures when using JGit to manage repositories in temporary directories. JGit uses lock files that it cleans up in background threads. JGit and JUnit will race to delete the lock file, and the JUnit TempDirectory cleanup fails when JGit wins that race.

I considered what an automated test for this new behavior would look like. I could add a clear-box test that uses high-level concurrency objects to make sure that the test can delete a file between the time that the SimpleFileVisitor lists the temp directory and the time that the SimpleFileVisitor attempts to delete the file, but this would require adding new seams to TempDirectory that are inconsistent with the existing tests for that type. Would you accept this change without adding new test coverage?

---

I hereby agree to the terms of the JUnit Contributor License Agreement.

---

Definition of Done

• There are no TODOs left in the code
• Method preconditions are checked and documented in the method's Javadoc
• Coding conventions (e.g. for logging) have been followed
• Change is covered by automated tests including corner cases, errors, and exception handling
• Public API has Javadoc and @API annotations
• Change is documented in the User Guide and Release Notes

[marcphilipp]

I considered what an automated test for this new behavior would look like. I could add a clear-box test that uses high-level concurrency objects to make sure that the test can delete a file between the time that the SimpleFileVisitor lists the temp directory and the time that the SimpleFileVisitor attempts to delete the file, but this would require adding new seams to TempDirectory that are inconsistent with the existing tests for that type. Would you accept this change without adding new test coverage?

Given that such a test would likely be flaky I don't think adding it would be justified. I'd be okay with making an exception in this case.

[marcphilipp]

@gilday Thank you for your contribution! 👍