My editor's background linter filled the one drive I had left, 341GB at a time

My editor's background linter filled the one drive I had left, 341GB at a time. The number I want to start with is 0.82GB free on C:. Measured on September 1, 2026, on a machine with a single NVMe partition system drive, after weeks of a Rust project growing in the background.

With only a gigabyte remaining, Windows began refusing operations quietly. Determining the cause took longer than fixing it once identified. The project had a rule: cargo only runs inside WSL, separate from Windows-native or PowerShell terminals. This rule was adhered to by all builders and testers.

What wasn't covered by the rule was the editor. VS Code's Rust extension uses rust-analyzer, which conducts its own background cargo check on every save, independent of human activity in the terminal. Using its own knowledge of the project's build directory, rust-analyzer writes to a Windows-native target\debug folder, unaware of the WSL rule.

Seventeen processes running simultaneously, mid-write, revealed the source of the bleed. The built folder measured 341GB, confirmed as regenerable cargo output by the presence of a CACHEDIR.TAG file, marking it safe for deletion and rebuild. The rule didn't bind the breaking factor, as rust-analyzer's flycheck feature, a separate writer, ignored it.

To stop the bleed, two actions were needed: killing the seventeen active processes and disabling three VS Code settings allowing rust-analyzer's flycheck to interact with the native build directory. The 341GB was only one of three sources, not the entire story. WSL had 630GB of stale cargo target/ directories from uncleaned sessions. The WSL virtual disk, the Linux filesystem container, also didn't shrink after deletion, a distinct fact requiring its own article.

In total, cleanup and compaction recovered nearly 1TB, reducing the container from 845.4GB to 173.4GB, a 672GB decrease measured directly before and after. The most significant change I made was recognizing that writing a resource discipline down, such as "cargo builds happen in WSL," required considering what else could write to the same resource that hadn't been named.

An editor extension, scheduled task, or second person's session sharing the same checkout could also write to the resource, and rules that name one writer and stop there are already losing against every writer they didn't account for, which this one had been doing quietly for an unknown duration before the free space hit zero.