{
  "id": 5220091,
  "title": "My editor's background linter filled the one drive I had left, 341GB at a time",
  "url": "https://urgent.news/2026/09/03/my-editors-background-linter-filled-the-one-drive-i-had-left-341gb-at",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-03T01:37:29.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/mahirhir/my-editors-background-linter-filled-the-one-drive-i-had-left-341gb-at-a-time-1cic"
  },
  "original_language": "en",
  "account": "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.\n\nWith 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.\n\nWhat 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.\n\nSeventeen 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.\n\nTo 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.\n\nIn 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.",
  "summary": "My editor's background linter filled the one drive I had left, 341GB at a time The number I want to start with: 0.82GB free on C:. Measured 2026-09-01, on a machine whose only system drive is a single NVMe partition, after weeks of a Rust project growing in the background. Below a gigabyte, Windows starts refusing things quietly, and figuring out why took longer than fixing it once we knew. The…",
  "key_points": [
    "Editor's background linter filled 341GB of one drive space",
    "Cleanup and compaction recovered nearly 1TB, reducing container from 845.4GB to 173.4GB"
  ],
  "editors_take": "Ignoring one writer when writing resource discipline leaves it vulnerable to undisciplined changes by unaccounted actors, quietly undermining rules meant to govern access and usage.",
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}