`get_available_space` failure silently bypasses the disk-space guard by returning `u64::MAX`

[forkwright]

Finding

get_available_space returns u64::MAX on any df failure (missing binary, permission error, unexpected output). check_disk_space compares this value against needed = archive_size * 1.1. Because u64::MAX is always greater than or equal to any realistic needed, the guard always passes when df fails, and extraction proceeds with no free-space verification.

Evidence

crates/ergasia/src/extract/pipeline.rs:209:

return u64::MAX;

The only failure signal is a tracing::warn! at line 208. The caller check_disk_space at line 167 receives u64::MAX and performs no further validation, so the comparison against needed is vacuously satisfied.

Why this matters

Any environment where df is absent from PATH (a minimal/stripped image) or fails (a network or restricted mount) silently disables the only defence against filling the target partition. Extraction then runs until the OS itself returns write errors, leaving a partially extracted archive on disk and surfacing opaque OS errors instead of an early, actionable failure. An operation that should refuse to start instead reports progress while corrupting the on-disk state — the precise failure mode a hostile or degraded environment can induce to mask incomplete writes.

Desired correction

Return Result<u64, ErgasiaError> from get_available_space and propagate the failure through check_disk_space so callers surface it. Alternatively, query free space via a crate that avoids a subprocess and reports failure explicitly (e.g. fs2::available_space). Done when: a df failure causes extract_archives to return an error rather than silently proceeding with extraction.