Series · The Quiet Machine · Part 2

Reclaiming 27.6 GB From an Old Dev Machine

August 16, 2026 · 5 min read · The Quiet Machine · Part 2

Android Studio, Flutter, Unity, JetBrains, the whole JVM zoo: all wiped months ago. And yet D:\ was still choking under 27.6 GB nobody was using.

Uninstalling a tool doesn’t uninstall its cache. Caches squat in AppData and hidden .gradle folders long after the app that made them is gone.

Before this 2021 tower could become a headless local-AI server, it needed a cleanup. What I care about more than the number is the space I didn’t delete: twice, the “obvious junk” turned out to be anything but.

The rule, before touching a single byte

I’ve rm -rf‘d my way into regret before, so this time the rule was narrow: every deletion scoped to a path I could name and justify, nothing wildcarded, anything ambiguous opened and checked before it got touched.

Same restraint as the BIOS tuning in Part 1: skip the aggressive move when it doesn’t pay off. On a server I’d rarely sit in front of, one deleted save file costs more than a spare 2 GB is worth.

Layer 1 — the archive builds (2.64 GB)

The machine had an archive directory full of old project snapshots, and buried in them were 105 build folders: build/, .gradle/, bin/, obj/, node_modules/, .dart_tool/. All regenerable, none worth keeping.

But “delete every build folder” is exactly the kind of command that eats something it shouldn’t, so the deletion was fenced three ways: only paths inside the archive directory, never a .git folder, never a source file. A build folder is disposable because the source that generated it still exists; delete the source by accident and the build folder is the least of it. 2.64 GB gone, clean conscience.

Layer 2 — the orphaned caches (21.7 GB)

This is where the real weight was. Uninstalling an SDK almost never removes what it downloaded.

  • Android emulator system images: 14.7 GB, and there were no AVDs defined on the machine. Not one. Multi-gigabyte OS images for devices that never existed, sitting there for nothing.
  • Unity: 1.87 GB, untouched since 2021.
  • NDK leftovers, a Dart analysis cache, JxBrowser, a Yarn cache dated 2022, Azure Functions tooling: smaller amounts, same story.

The emulator images made the point on their own: a feature I never used was the single largest thing on the drive.

Layer 3 — the safe junk (3.07 GB)

The uncontroversial tier: Windows Update cache (1.54 GB), old NVIDIA installer packages (1.21 GB), crash dumps (0.32 GB). No judgment calls: these regenerate or they’re just stale, the kind of cleanup you can do half-asleep.

Fixing PATH

Reclaiming disk space turned out to be the smaller job. What needed fixing was PATH, which had rotted into a graveyard of dead tools:

jdk-16, jdk-17, IntelliJ, PyCharm, Flutter 2.8.1,
heroku, Azure Data Studio ... and two stray ";;"

Nine entries pointed at directories that no longer existed, plus five case-duplicate System entries, any one able to shadow the tool you meant to run.

I dumped the entire variable to a file first, since a corrupted PATH can cost you the ability to run the tools you’d need to fix it, then trimmed it down to 20 clean entries.

The catches that justified the paranoia

Catch 1: the “junk” that was someone’s save file

Two folders (call them TL and Discovery) sat in the middle of a directory full of disposable clutter, cryptic names, no obvious owner. My first instinct was to sweep them into the delete pile with everything else. I opened them first instead.

Inside: Unreal Engine games, with SaveGames directories. Not caches. Someone’s progress, hours of it, in folders that just happened to have unhelpful names. Sweeping them on instinct would have thrown away save data no reinstall gets back.

Catch 2: the 38 GB that wasn’t real

Two Application Data folders reported 7.5 GB and 38 GB. Neither number was real. Both were recursive junction points: Windows reparse points that loop back on themselves, so a directory-size walk counts the same bytes over and over. The 38 GB was a double-counting artefact, not disk space.

Deleting the junction would have done nothing good and risked cascading into real data through the link, so I left both alone.

A folder’s size and its name both lie. Discovery didn’t say it held save games, and 38 GB didn’t correspond to any real bytes on disk. The only thing that told the truth was opening the folder and looking, which is exactly the step a blind rm -rf skips.

The tally

Archive project builds ......... 2.64 GB   (guarded, inside-archive only)
Orphaned dev caches ........... 21.70 GB   (14.7 GB of it: emulator images, zero AVDs)
Safe system junk ............... 3.07 GB   (WU cache, NVIDIA installers, dumps)
                                --------
Total reclaimed ............... ~27.6 GB   (rounded; the three layers above sum to 27.41 GB)
PATH: 20 clean entries (from a graveyard), backed up first.
Deleted in error ................... 0 B

Not one byte of that 27.6 GB was a save file, a junction phantom, or a live dependency. The tradeoff: going slow enough to open every ambiguous folder cost maybe twenty extra minutes I wouldn’t have spent on a blind rm -rf. Two of those folders would have been a real loss if I hadn’t.

With the disk breathing again, the next problem was getting into the box at all: standing up OpenSSH on a machine with no monitor, and the two silent-failure gotchas that ate an evening before a key would authenticate.