fix: lock state and settings file updates

[ychampion]

Summary

• Add locked read/write helpers for file contents.
• Use them for state.toml and settings.toml reads and writes.
• Cover locked write truncation with a unit test.

Why

Fixes #4942. These files can be touched by concurrent rustup processes, so writes now take an exclusive lock before truncating and reads take a shared lock.

Validation

• cargo test --features test locked_file_round_trip_truncates_previous_contents — passed
• cargo test --features test settings::tests — passed
• cargo test --features test --test test_bonanza notify_release_hint — passed
• cargo check --all-targets --features test — passed
• cargo clippy --all-targets --features test -- -D warnings — passed
• cargo fmt --all -- --check — passed
• git diff --check — passed

[rami3l]

LGTM, thanks! Please squash the two commits into one and I'll merge it shortly after.

View changes since this review

[ychampion]

Squashed into one commit now. I reran the locked-file regression plus fmt/diff checks after the rewrite.

[rami3l]

@ychampion The CI is failing but it's probably not your fault; it might be due to an upstream update of Rust.

Since we are at it, would you mind fixing the clippy warnings in a separate commit? Many thanks in advance 🙏

[djc]

Linting issues might be from Rust 1.97 release that just dropped.

Personally I don't like splitting this code between utils/mod.rs and utils/raw.rs; maybe just keep the "raw" variants just below the utils functions?

View changes since this review

[rami3l]

Personally I don't like splitting this code between utils/mod.rs and utils/raw.rs; maybe just keep the "raw" variants just below the utils functions?

@djc I see your point but refactoring PRs can always follow this one... I would prefer not putting too much pressure on first-time contributors in fixing our pre-existing issues WRT code organization, if you agree 🙏

[djc]

@djc I see your point but refactoring PRs can always follow this one... I would prefer not putting too much pressure on first-time contributors in fixing our pre-existing issues WRT code organization, if you agree 🙏

I might agree but I guess I put less value on seemingly drive-by contributions that seem clearly LLM-assisted.

[ychampion]

Done in 42a5b3e as a separate commit.

Validation:

• cargo clippy --all-targets --all-features -- -D warnings on Rust 1.97.0
• cargo fmt --all -- --check
• cargo test --features test --test test_bonanza add_target -- --nocapture

[ychampion]

@djc That's fair. I can move the raw helpers back beside the existing utils functions if you'd prefer that in this PR; I kept the latest push to the requested Rust 1.97 Clippy-only cleanup.

[djc]

@djc That's fair. I can move the raw helpers back beside the existing utils functions if you'd prefer that in this PR; I kept the latest push to the requested Rust 1.97 Clippy-only cleanup.

Okay, let's keep it as is for now. Would be nice if you can clean up single caller raw variants in a next PR.

Please rebase, since the Clippy fixes are already on main.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[ychampion]

Rebased onto current main. The separate Clippy cleanup dropped out because it is already present there; the locking change itself is unchanged.

[rami3l]

That's fair. I can move the raw helpers back beside the existing utils functions if you'd prefer that in this PR; I kept the latest push to the requested Rust 1.97 Clippy-only cleanup.

Okay, let's keep it as is for now. Would be nice if you can clean up single caller raw variants in a next PR.

@ychampion Would you mind evaluating the proposed clean-up of the raw module and, if feasible, make a follow-up PR? Many thanks in advance 🙏