fix: use random temporary directory in test

[mgeisler]

Summary of the PR

While trying to enable the unit tests in Android (see https://r.android.com/3044134), I noticed test failures saying:

thread 'errno::tests::test_errno' panicked at
external/rust/crates/vmm-sys-util/src/errno.rs:156:14:
called `Result::unwrap()` on an `Err` value: Os { code: 21, kind:
IsADirectory, message: "Is a directory" }

I believe this is because of the hard-coded name for the temporary file in the test_errno unit test.

Using a randomized temp directory should fix this.

Requirements

Before submitting your PR, please make sure you addressed the following requirements:

• [x] All commits in this PR have Signed-Off-By trailers (with git commit -s), and the commit message has max 60 characters for the summary and max 75 characters for each description line.
• [x] All added/changed functionality has a corresponding unit/integration test.
• [x] All added/changed public-facing functionality has entries in the "Upcoming Release" section of CHANGELOG.md (if no such section exists, please create one).
• [x] Any newly added unsafe code is properly documented.

[mgeisler]

Using a randomized temp directory should fix this.

Right after implementing this, I noticed https://github.com/rust-vmm/vmm-sys-util/blob/main/src/tempfile.rs :slightly_smiling_face: I don't really know the crate here, so would it be better to use the functionality there?

[mgeisler]

Hi! Thanks for this PR! I agree that the failure you're seeing it because of the hardcoded path in the test. Probably something else on the system created a test directory inside /tmp, and so the test fails when it tries to create test as a file. (assuming that no one created something called "test" inside of /tmp is indeed bold of this test, haha)

Yeah, it's the kind of hidden assumption that works fine for a long time, until it doesn't because someone has an unexpected setup :smile:

As for tempfile, let use the module from vmm-sys-util. We try to keep the dependencies on these crates minimal, so since its an easy change to use our module here, that'd be preferred.

Alright! I applies your suggestion to use TempFile from this crate, but tweaked them a bit. I think using the temporary file directly does something slightly different, but I'm not sure if it matters? Before the test file did not exist when open() was called. If we use the temp_file directly, the file exists — and I guess it's a bit of a coincidence that the flags match up?

To avoid reasoning about this, I now simply delete the temp_file early and then reuse the path (with the assumption that nobody is trying to race me).

Please let me know if you think this is overkill?

[roypat]

As for tempfile, let use the module from vmm-sys-util. We try to keep the dependencies on these crates minimal, so since its an easy change to use our module here, that'd be preferred.

Alright! I applies your suggestion to use TempFile from this crate, but tweaked them a bit. I think using the temporary file directly does something slightly different, but I'm not sure if it matters? Before the test file did not exist when open() was called. If we use the temp_file directly, the file exists — and I guess it's a bit of a coincidence that the flags match up?

I also don't think it really matter, as long as we do something that causes a well-known errno to be set (e.g. reading from a file opened with O_WRONLY resulting in EBADF).

To avoid reasoning about this, I now simply delete the temp_file early and then reuse the path (with the assumption that nobody is trying to race me).

Please let me know if you think this is overkill?

No, this is perfectly fine, thanks for fixing this!

[mgeisler]

Thanks, I'm glad you like it! The tests will then soon also be running as part of the Android build: https://r.android.com/3044134.