Replace unmaintained fs2 with fs4, enabling illumos support

[plaidfinch]

fs2 v0.4 has no cfg arm for target_os = "illumos" (the target split out of "solaris" some time after fs2's last release), so cargo-mutants does not build there. fs4 is the maintained fork of fs2 with the same flock-based locking and support for current targets (including this one); its sync feature alone suffices for the uses in cargo-mutants.

There is one interface difference between fs2 and fs4 worth calling out explicitly (it is remediated in this patch): fs4's try_lock_exclusive returns Ok(false) for a held lock instead of Err(EWOULDBLOCK), so the wait loop now distinguishes contention (keep polling) from real errors (propagate with context) rather than retrying forever on any error. I believe this is a strictly beneficial change, but it is a behavioral change, so I wanted to flag it.

This patch also incidentally allows dropping the old kernel32-sys and winapi v0.2 transitive dependencies that fs2 previously pulled in on Windows.

[sourcefrog]

Looks reasonable, we should just also mention it in the NEWS.

[Copilot]

Pull request overview

Replaces the unmaintained fs2 dependency with fs4 to restore/build support on target_os = "illumos" and modernize the lock-file implementation behavior.

Changes:

• Swap fs2 for fs4 (sync-only, no default features) in dependencies.
• Update lock.json acquisition loop to handle fs4’s try_lock_exclusive -> Result<bool> semantics, retrying only on contention and propagating real errors with context.
• Update Cargo.lock to reflect the new dependency tree (dropping fs2 and its older Windows transitive deps).

Reviewed changes

Copilot reviewed 2 out of 3 changed files in this pull request and generated no comments.

File	Description
src/output.rs	Switches file-locking trait import to fs4 and adjusts the retry loop to distinguish lock contention from errors.
Cargo.toml	Replaces fs2 with fs4 configured for sync-only usage.
Cargo.lock	Updates the resolved dependency graph to remove fs2 and include fs4.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[sourcefrog]

Also, this seems to break the Windows tests: could you please take a look? Thanks

[plaidfinch]

This is very strange; I'll look into it, with the caveat that I don't have a Windows box to play around on locally.

[plaidfinch]

Also, this seems to break the Windows tests: could you please take a look? Thanks

@sourcefrog I've poked at this (using LLM assistance to make more sense of the build logs), and I think the failures on Windows are due to a regression in the nightly Rust on Windows: your path-lengths in the test runner setup are close to the maximum path length of 259 chars, and build-dir layout v2 was recently enabled by default on nightly, which adds length to the build directory paths. In your case I think it pushes it over the limit and you get a generic linker failure on Windows under the nightly toolchain. I suspect that this happened on this PR in particular simply because it was the first PR to land since the relevant update to nightly, and that the failures are uncorrelated with the actual content of the PR.

When the build-dir layout v2 changes hit stable, you'll probably want to have changed cargo-mutants so that it uses shorter paths for tempfiles; I leave this to your taste since I have not had enough time to familiarize myself with your codebase to PR this, but Claude suggests something like this might work:

/// Windows' 259-char usable MAX_PATH is tight once cargo's build-dir layout
/// nests artifacts under `build/<pkg>/<hash>/out/`, so keep this short.
fn temp_dir_prefix(source: &Utf8Path) -> String {
    const MAX_NAME: usize = 16;
    let name = source.file_name().unwrap_or("unnamed");
    let short: String = name.chars().take(MAX_NAME).collect();
    format!("mutants-{short}-")
}

Let me know if I missed something here! I have not tested this, only poked around briefly!