Finding large files alternatives: what you can drop

The search for an alternative to a disk space scanner almost always starts within a minute of the startup disk warning appearing. Installing something is the obvious next move, and it is worth pausing for ten minutes first, because the job being described as one task is four, and macOS already answers three of them without anything installed. What is left over is a short list, and that short list is a much better shopping brief than a feature comparison.

One phrase covering four different questions

Finding large files means different things depending on what happens next.

• Free space now. Any thirty gigabytes will do, the source does not matter
• Understand what grew. Which directory got fat, and roughly when
• Decide whether a specific file can go. This one needs knowledge, not measurement
• Stop it happening again next quarter

These need different tools. The first is answered by a top ten list. The second needs a comparison against a previous state, which almost nothing keeps by default. The third is not a measurement problem at all, it is a question about what a file is for. The fourth is a settings question wearing a disk usage costume.

The time each takes differs too. The first is over as soon as a sorted list appears. The third means opening items one at a time and thinking about each. Installing a tool built for the third question while actually needing the first is how an urgent fifteen minute job becomes an afternoon, and the richer the feature set, the longer the detour.

What macOS already answers

System Settings, General, Storage shows a breakdown by category. Where a category has a More Info button, its contents can be opened and sorted, and that is the part most people have never clicked.

Under Documents the detail view splits into tabs. Large Files is a plain list sorted biggest first. Downloads collects downloaded files and installers. Unsupported Apps lists software that no longer runs on the current version of macOS. File Browser walks the folder tree with a size next to each level. For the first of the four questions, the first tab is the entire answer.

Other categories carry their own breakdowns. Developer Tools separates Xcode Caches, iOS Device Support and Xcode Project Build Files. iOS Files holds Device Backups and iOS Installers. Applications distinguishes Older Versions and Duplicates. Trash offers Empty Trash Automatically, which erases anything sitting there for more than thirty days.

On a machine used for development, the biggest items are usually sitting in one of those named categories, which means identifying the culprit needs no software at all. Music creation software keeps its own entry for downloaded sound libraries, and Books, Podcasts and TV each offer removal of content that can be downloaded again later. Those categories are easy to skip past because they sound small, and on a machine that has had the same account signed in for years they frequently are not.

The boundaries matter as much as the contents. Other user accounts appear as a total and cannot be opened. Disconnected external drives and network shares are not counted. A photo library shows as a single item even when it holds tens of thousands of files inside the package. What this screen reports is the current startup disk, within the parts of it the logged in account has rights to. Chasing a missing thirty gigabytes without knowing that boundary is a long evening.

The built in route has no undo

There is one property of this screen that is better learned before using it than after. Deleting from the list produces a confirmation reading, in Apple's own wording, that the item will be deleted immediately and that the action cannot be undone.

Nothing goes to the Trash. The item is gone at the moment of the click, with no recovery path short of a backup.

For a quick pass over obviously disposable installers that is acceptable. For working through a list of two hundred items while making judgement calls, it is the wrong instrument, because that kind of session assumes a certain number of mistakes. This single property is the most defensible reason to install something else, and it reframes what to look for: not prettier visualisations, but whether deletions route through the Trash and whether a record of what was removed survives the session.

Why the totals never add up

Anyone who reads the breakdown closely notices the categories do not sum to the used space. Two things cause that.

The first is a category that exists to hold everything else:

The category named System Data (or Other) is a general category that measures the storage space used by all Apple and third-party files that don't belong to any more specific category. Source: support.apple.com

That is a naming gap, not a mystery. Forty gigabytes of System Data does not mean forty gigabytes of deletable junk, and treating it as a target leads people into directories that should be left alone.

The second is space that is already reclaimable. Local backup snapshots and caches that can be rebuilt on demand are counted as used, and macOS releases them automatically when free space runs short. The number on screen is honest, it just describes a state that resolves itself under pressure.

The reclaimable half can be inspected directly rather than guessed at. tmutil listlocalsnapshots / prints the local backup snapshots currently held on the startup volume, each one dated. A machine that has been away from its backup destination for a while accumulates several, and seeing the list turns an unexplained gap into a number with names attached. Nothing needs deleting as a result, since the system thins them under pressure, but knowing they exist stops the hunt for phantom gigabytes that were never lost.

How a replacement handles these two is a genuine differentiator. Reporting unclassifiable space as unclassifiable is more useful than inventing a confident label for it.

Three commands that cover most of it

For anyone comfortable in a shell, the measurement half of this job is three lines, and they are worth learning together because each one misses something the others catch.

du -h -d 1 ~ reports usage per folder one level below home. It stops at that depth, so it returns quickly and shows immediately which top level directory is carrying the weight.

find ~ -type f -size +1G lists every file over a gigabyte regardless of where it sits. This catches the case a folder level view hides: a directory that looks small in aggregate but contains one enormous file.

mdfind 'kMDItemFSSize > 1000000000' asks the Spotlight index the same question, so it answers faster than a scan. The trade is that anything outside the index is invisible to it, including excluded folders and unmounted volumes.

The shell route also crosses a boundary the Storage screen will not. Pointing du -h -d 1 at a mounted external volume, an archive disk or a network share returns the same per folder breakdown as it does for home, which matters because the drive people actually fill is often not the startup disk. Running it against a volume over a network is slow enough to be worth doing once and saving the output to a file, then reading the file rather than repeating the scan.

The mismatch between the first two is worth understanding rather than debugging. du counts blocks actually occupied, so a file evicted to the cloud reports close to zero. find reads the recorded file size, so the same file reports at full size. Neither is wrong. The question being asked is either how much space can be reclaimed right now, in which case du answers it, or how big something would be if brought back, which is find.

APFS clones create the same effect from the other direction. Cloned files share their underlying blocks, so adding up per file sizes can exceed what the volume actually holds. Chasing a total that reconciles is not a good use of an evening. The ranking is what the decision needs, and the ranking is reliable.

Features worth dropping

Four things commonly sold as core turn out to be optional for this job.

Treemaps and pie charts. Showing size as area is genuinely pleasant to look at and rarely changes a decision. A sorted list of the top twenty leads to the same conclusion in less time.

Background monitoring. Reclaiming disk space is a monthly errand at most. A process resident for thirty days to be useful on one of them is a poor trade in memory and launch time.

One click automatic cleanup. Automating an irreversible operation optimises for the wrong risk. The space recovered is cheaper than one wrongly deleted project archive.

Duplicate detection. Most flagged duplicates are deliberate copies, exports or backups. The list still has to be reviewed one item at a time, which is where the time goes, so detection saves less than it appears to.

Dropping those four widens the field considerably. A tool built around them is aimed at a different problem than the one at hand.

Features not worth dropping

Three are worth holding out for.

Honesty about what it cannot see. Other accounts, unmounted volumes and folders without granted access cannot be measured. Silently counting them as zero manufactures exactly the unexplained gap that started the search.

Looking inside packages. A photo library, an editing project, an app bundle: each is one item to the Finder and a directory tree underneath. A tool that stops at the package boundary will never name the largest thing on the disk.

A list before, and a record after. Seeing what is about to be removed, and being able to answer next week what was removed, is precisely what the built in route does not offer. That gap is the whole reason to add something.

The question no scanner answers

The fourth question from the opening list, stopping the growth, is immune to every tool discussed here. Listing tools report an outcome and never touch the mechanism that produced it. That part is configuration.

The mechanisms are predictable. Downloaded files and installers accumulate because nothing ever removes them. Turning on automatic Trash emptying closes the path where discarded items linger. Build artifacts from development tools spread across project directories, and consolidating them into one location makes an expiry policy possible. Rendered video and image exports belong on an external or shared volume as the final step of the job rather than as a later cleanup.

Doing this before the audit rather than after is what makes the next audit shorter. Reversed, the same list gets reviewed every few months. Most people shopping for an alternative are tired of the repetition rather than dissatisfied with the measurement.

What to change first

Open System Settings, General, Storage, read the Large Files tab, and clear the obvious installers today. Then decide which of the four questions actually applies, because that determines whether anything needs installing at all. If the real cost turns out to be the trips between a list, a folder window and a terminal while deciding what each item is, that is a workflow constraint rather than a measurement one, and the comparison of file managers sets out the axes, with Atriens built to keep those steps in one window.