Finding large files: the setup order that holds up

Most large-file cleanups begin by launching a scanner, and that is already the wrong first move. The scan is cheap. What decides whether the next two hours produce anything is a handful of choices made before it runs: how much space is enough, what is out of scope, and what counts as large on this particular disk. Skip those and the output is a list too long to read, which gets skimmed from the top and abandoned. The order below is arranged so that each step narrows the next one.

Step one: write down the number and the deadline

Deciding how much space to recover is not optional, because without it the work has no end condition and stops only from fatigue.

Setting the figure is arithmetic. Take whatever needs to fit, then add operating headroom. macOS needs scratch space for updates and large copies, so keeping roughly ten percent of the volume free keeps those operations from stalling. On a 512 GB disk that puts the target near 50 GB.

Fix the deadline in the same breath, because it changes the plan rather than just the pace. One hour means looking at the top twenty entries, deleting only what is trivially recreatable, and stopping. A weekend means moving originals to external storage and fixing whatever keeps generating the bytes. Starting without deciding guarantees drifting into the heavy version of the work and quitting partway through it.

One more thing belongs before the scan: confirming that a recent backup exists. This step involves moving and deleting, and a stale backup turns one bad judgment into permanent loss. Check the date first. If it is old, run the backup and start afterward. This is the one ordering in the whole procedure that should never be swapped.

Step two: decide the exclusions before deciding anything else

Procedures that open with a scan produce the same top entries every time, and reading past them costs time on every run. Excluding first fixes that permanently.

Three groups are worth excluding by default:

• Things already ruled untouchable. Photo and video libraries, device backups, the working folder for current projects.
• Space that frees itself. Startup disk snapshots are released automatically when something else needs the room, so listing them produces no actionable line.
• Other user accounts, and external volumes that are not being addressed on this pass.

The effect is not cosmetic. A 200 line list that becomes 40 lines is a list that gets finished. Treemap applications expose an exclusion setting; on the command line the same result comes from naming narrower paths.

Scan scope is decided alongside exclusions, because it determines what permissions are needed. Covering the whole startup volume means granting the scanning application full disk access first. Without it, unreadable areas are counted as zero, the total comes out low, and a conclusion gets drawn from a number that was never complete.

Exclusions are worth revisiting once a year rather than treating as permanent. A folder that was untouchable because a project was live becomes an ordinary archive candidate once that project ships. Leaving it excluded forever means the largest recoverable block on the disk never appears in any list. Dating the exclusion file makes this easy to notice: any line older than a year gets re-examined before the next scan.

Step three: derive the size threshold instead of guessing it

Asking what counts as a large file has no universal answer, and reusing a fixed number across machines produces an unreadable list on one disk and an empty one on another.

Derive it from the target instead. Divide the space needed by the number of items that can realistically be judged in the time available. Recovering 50 GB while able to assess twenty items means each item needs to average 2.5 GB, which puts the threshold near 1 GB with room to spare. Setting it at 100 MB produces hundreds of candidates and the list stops being usable.

Once chosen, the threshold goes into the scan condition. Finder search accepts a file size rule and the resulting condition can be saved, so the second run is a matter of opening it. On the command line, find takes a size predicate and returns only what exceeds it.

The first threshold is rarely the right one. Look at how many rows came back, raise it if there are too many, lower it if there are too few. Three iterations is usually enough to land on a figure that suits the disk, and that figure is worth writing down for next time.

Step four: read the same volume in three passes, coarse to fine

Changing how the output is shaped changes what becomes visible. Going coarse to fine keeps the number of lines read small at every stage.

Pass	What to run	What it reveals
First	Totals per folder, sorted by size	Which container is heavy
Second	One level inside the heavy containers	Where inside it the weight sits
Third	Files matching the size threshold directly	Single files big enough to matter alone

The first two passes are the same command with a different depth. That depth flag has a specific meaning:

Show the total for each directory (and file if --all) that is at most MAX_DEPTH levels down from the root of the hierarchy. Source: gnu.org

Resisting the urge to descend all the way at once is the whole trick. A full depth listing runs to thousands of rows and buries the heavy entries among them. Descending one level, picking the three heaviest containers, then descending one more level inside only those three keeps each reading to roughly twenty rows.

The third pass looks for individual files rather than containers. Video exports, virtual disk images, uncompressed source material: anything that is enormous on its own surfaces here and nowhere else. The first two passes are strong on many small files, the third is strong on few enormous ones, and running only the third means missing the tens of gigabytes that accumulated in fragments.

After one trip through all three, the shape of the disk can be stated in a sentence. Something like: the weight is under documents, half of it is video exports, the rest is material from finished projects. Once that sentence exists, the next action is obvious rather than arbitrary.

Step five: sort every candidate into exactly three buckets

Keeping the options to three keeps deliberation short, which is the only thing that makes a long list survivable.

• Delete. Recreatable. Build intermediates, dependency caches, installers still available from the vendor.
• Move out. Irreplaceable but rarely opened. Finished project material, camera originals.
• Leave. Opened weekly, or required by something currently running.

Anything ambiguous goes into move out. The space is recovered immediately and the delete decision is deferred rather than forced. Whatever has not been opened three months later can be reclassified on the next pass.

Before moving anything, settle on how the external drive will be organised. An external volume that becomes as disorganised as the internal one makes retrieval slower than leaving the files where they were, and the material eventually migrates back. By year and project, or by type, either works. Not changing the scheme halfway matters more than which scheme wins. Delete the emptied folders afterward as well, since empty directories clutter the next scan with names that carry no weight.

Cloud offloading is a fourth option that looks like a shortcut:

Your Mac can optimize storage by using iCloud to automatically make more storage space available when needed. Source: support.apple.com

It is genuinely convenient, and it removes the local original. Anything that has to open without a network connection does not belong in this bucket. Weighing the cost of extra storage against the cost of tooling is easier with the figures in front of you, and those are listed on the Pricing page.

Step six: turn the procedure into something reusable

The reason this job feels heavy is that the conditions get rebuilt from scratch every time. Preserve three artifacts from the first run and the second takes about ten minutes.

Those three are the saved search containing the size threshold, a short alias for the commands that produce the first and second passes, and the exclusion list. Keep them somewhere portable rather than buried in an application's settings, because settings do not follow you to the next machine. A single text file in a working folder is enough. Append a dated line each run recording the threshold used, what was excluded, the free space before, and the total removed. After three runs the effective fixes are visible as numbers rather than impressions.

Pick a cadence too. Monthly on a fixed date, or triggered when free space drops below the target. The trigger wastes less effort but arrives later, so keeping a free space indicator visible is the practical compromise.

There is a limit to how far this should be automated. Scheduling an unattended deletion of anything that matches a size rule is how irreplaceable material disappears quietly, since size was never a reliable signal for whether something can be recreated. Automate the measuring half and leave the deciding half manual. The measurement can run on a timer and leave its output somewhere to be read later; the removal stays a deliberate act.

Step seven: expect the second month to undo the first

Run the same procedure again and the top entries will look familiar. That is not a flaw in the procedure. It means nothing has touched whatever is producing the bytes.

Count the parent folders of the top twenty entries. Any parent appearing three or more times is the source, and it is nearly always an export destination set long ago, a download location, or a retention setting keeping more generations than anyone needs. The remedy is one of three: repoint it at external storage, reduce the retained count, or empty it on a schedule.

Apply one remedy at a time and check the free space figure on the following run. If the decline has flattened, it worked. If nothing changed, the diagnosis was wrong and the parent folders are worth counting again. Changing three things simultaneously leaves no way to know which one mattered.

What to set up first

Before adjusting any tool, run through the first three steps on paper: the target number, the exclusion list, and the derived threshold. Most stalled cleanups are missing all three, and none of them require installing anything. If those are already in place and the work still consumes an afternoon, count the windows opened per decision instead, then look at what a file manager with a built-in terminal changes about that count and how it compares on the Compared with other file managers page. Details on Atriens cover the questions that come up before switching.