Finding large files: what it does and where it breaks down

The disk warning appears, the Downloads folder gets opened, and nothing about it says which file is heavy. Sorting by size helps for one folder and then stops helping, because the weight is rarely in the folder that was opened first. finding large files, finding and clearing the large files on a Mac, looks like a single task that a better tool would finish. It is two tasks, and the tool only does one of them. Knowing which half is stalled is what decides whether the next hour is useful.

The job is measuring plus deciding, and only one half is automated

Measuring means producing a list of what occupies how many bytes, sorted by weight. A machine does this well. The time it takes depends on how many files exist and how fast the volume reads, and when the scan finishes there is an answer.

Deciding means taking each line of that list and sorting it into keep, move, or delete. No scanner does this, because the information needed is not in the file system. An 8 GB video file could be a stale export that nobody will open again, or the only surviving copy of footage that was never backed up. Size does not distinguish them. Name, location, date, and memory do.

This is why replacing the scanner rarely shortens the job. A large-file list arrives in roughly ten minutes with almost any tool. What follows is the expensive part: open the folder in Finder, preview the contents, check in a terminal whether a duplicate exists elsewhere, then delete or move, then return to the list. Repeat that fifty times and the afternoon is gone, and the scan itself accounted for two minutes of it.

The practical consequence is that the useful question about a tool is not how fast it scans. It is whether a decision can be made without leaving the window the list is in.

There is a second consequence, less obvious. Because deciding is the slow half, the number of candidates matters more than the accuracy of the measurement. A list of forty items gets worked through. A list of four hundred gets skimmed and abandoned. Setting the size threshold high enough to produce a readable list is a bigger lever on the outcome than choosing between two scanners that both measure correctly.

Two tools reporting different totals are usually both correct

Running two size tools on the same folder and getting two numbers is normal. They are counting different things.

Apparent size is the number of bytes the file claims. Disk usage is the number of blocks the file system has actually allocated to hold it. A file with unwritten gaps inside it reports a large apparent size and a small allocation. A folder holding thousands of tiny files reports the opposite, because each one rounds up to a block. The command line exposes the switch directly:

Print apparent sizes, rather than file system usage. The apparent size of a file is the number of bytes reported by wc -c on regular files, or more generally, ls -l --block-size=1 or stat --format=%s. Source: gnu.org

There is a second source of disagreement. macOS has bundles, which are folders that present as a single item. Applications and photo libraries are the common ones. Finder shows one row. A treemap tool usually descends inside and draws thousands. The du command treats them as ordinary directories. The same 120 GB photo library is therefore one line or ten thousand lines depending on what is pointed at it.

A third source is cloning. APFS can create a copy that shares storage with the original until one of them changes. Some tools count both copies at full price, which makes the sum of the parts exceed the size of the disk. That is a counting artifact, not a corrupted volume.

None of this matters for a rough pass. It matters when a specific number is being defended, such as when a folder appears to hold 40 GB in one tool and 26 GB in another and the decision to delete rests on which figure is right. The way through is to stop comparing totals and compare methods instead: check whether one tool is descending into bundles, whether one is reading apparent size, and whether one is skipping paths it cannot open. Any one of those three explains a gap that large.

The four classes of tool, and what each one is actually for

Class	Examples	What it shows	Cost
System settings	Storage pane	Totals per category and Apple's own reduction suggestions	Included
Finder search	Saved search conditions	Files matching a size rule	Included
Treemap	DaisyDisk, GrandPerspective, OmniDiskSweeper	Size drawn as area, descends into bundles	Free to $9.99
Command line	du, find	Numbers, with conditions written by hand	Included

The built in pane is reached from a fixed place:

Choose System Settings from the Apple menu, click General in the sidebar, then click Storage on the right. Source: support.apple.com

Among the treemap tools, DaisyDisk is a one time purchase at $9.99 covering up to five personal Macs and requiring macOS 10.13 or newer. GrandPerspective is released under the GNU General Public License, free from SourceForge and $2.99 on the App Store, and its own page states that "You'll get the same app either way." OmniDiskSweeper describes its scope narrowly, as a way to "Quickly find large, unwanted files and sweep them into the trash."

The command line side covers the same ground with two shapes. du -sh * gives one total per item in the current folder. du -h -d 1 descends exactly one level and lists what is below. The -h flag appends a unit, and those units are computed in powers of 1024, not 1000, which is another reason a command line number and a Finder number can differ slightly for the same file. A side by side view of what each class of tool refuses to do is collected on the Compared with other file managers page.

Four places the scan stops being trustworthy

Space that will not free up no matter what is deleted

Time Machine keeps snapshots of the startup disk, and those snapshots occupy blocks. They are also managed automatically:

Your Mac counts the space used by snapshots as available storage. You don't need to think about how much storage space local snapshots are using, because they don't use the space needed for tasks like downloading files, copying files, or installing new software. Source: support.apple.com

Chasing that space manually is wasted effort. It is released when something else needs it.

Directories that require permission

Other applications' storage and system managed areas are unreadable unless the scanning app has been granted full disk access. An app without it either reports those paths as zero or skips them silently. A total that comes in lower than expected is worth checking against the permission list before any other theory.

External and network volumes

Reading over a network or a slow bus is tedious enough that the scan gets cancelled partway. A cancelled scan still prints a total, and that total gets treated as the answer. The heaviest item is frequently the one that had not been reached yet.

Paths excluded by default

Trash contents, other user accounts, and the inside of unmounted disk images are included by some tools and skipped by others. When two scans of the same Mac disagree by tens of gigabytes, the difference is almost always sitting in one of these four categories rather than in a bug.

The heaviest items are frequently the ones to leave alone

Sorting the list by size puts a predictable set at the top. Whether any of them can go depends on whether they can be recreated, not on how much they weigh.

• Photo and video libraries, where the originals may exist nowhere else
• iPhone and iPad backups, which matter precisely once, after a device is wiped
• Virtual machine disk images, tens of gigabytes each, disposable if the environment can be rebuilt
• Build intermediates and dependency caches, always recreatable, always safe to remove
• Installers left in Downloads, retrievable again if the vendor still publishes them

Location is the fastest tell. Items under the documents folder were usually put there by a person and are usually originals. Items under the user library, or inside a folder an application created for itself, are usually derivatives. A run of similarly named files with dates or sequence numbers is almost always export output.

Working through recreatable items first is worth doing for a practical reason beyond safety: those decisions take no thought at all, and they often account for most of the recoverable space. What remains afterward is the genuinely irreplaceable set, which is the only part worth moving to external storage. Keeping a path back to that external copy matters too, and reaching it from a phone or tablet is covered on the From iPhone and iPad page.

Why the disk fills back up within weeks

A cleanup that works and then undoes itself is not a failed cleanup. It is a cleanup that never touched whatever is producing the bytes. Something is generating them continuously: browser downloads, an export destination that was set once and forgotten, automatic intermediate files, retained backup generations.

The diagnostic is quick. Take the top twenty entries and look at their parent folders. If one parent appears three or more times, it is the source. Once identified, the fix is one of three things: point the export destination at external storage, reduce the number of retained generations, or empty it on a schedule.

That single step is the difference between a cleanup and a system. Without it, the same list reappears in six weeks with the same names on it.

Applying one fix at a time is worth the patience. Changing the export destination, trimming retained generations, and scheduling a purge all at once makes the disk emptier and leaves no way to tell which of the three was responsible. Next quarter, when the disk fills again, there is nothing to reason from. One change, then a look at the free space figure a few weeks later, produces knowledge that carries over to the next machine.

What to change first

Work out which half is stalled before changing anything. If the scan itself is producing wrong or incomplete numbers, the fix is permissions and scan scope, and no purchase is required. If the list is fine and the afternoon still disappears, the scanner is not the constraint and a faster one will not help. Count the windows opened per decision instead, and if the answer is three or more, look at what a file manager with a built-in terminal changes about that number, along with Atriens and the questions that come up before switching on the FAQ page.