Finding large files: how to decide what you need

Every option for finding large files claims to do the same thing, which makes a feature comparison almost useless for choosing between them. The differences that matter are not in the feature list. They are in what a given route is permitted to see, how it counts what it sees, and what it can do once the list exists. Five axes separate the routes cleanly, and most Macs are already disqualified from two or three of them before any comparison begins.

Start from the disk layout, not from the tool

Before reading a single product page, describe the machine in four lines. Where does the data actually live, how many accounts use it, how much of it is resident, and what happens to a file after it is found.

A laptop with one internal disk, one account, everything local, and a habit of deleting from a list is the simplest case, and the built in Storage screen answers it. Add an external archive drive and the picture changes, because the volume that fills up is no longer the one the Storage screen reports on. Add a second user account and a whole region becomes a single opaque number. Turn on cloud storage optimisation and the size of a file stops being a single value, since what it occupies and what it weighs are now different numbers.

Every axis below is really a question about that description. Someone whose data is entirely local, in one account, on one disk, can stop reading after the third section. The axes exist to eliminate options, not to score them.

Axis one: what it is allowed to see

Measurement tools report zero for places they cannot read, and zero is indistinguishable from empty in a sorted list. This is the axis that produces the most confusion, because failures here are silent.

Three permission boundaries exist on a modern Mac. There are the protected locations that require Full Disk Access, granted per application in Privacy and Security settings. There are other users' home directories, which need administrator rights and are reported only as a total. And there are volumes that are simply not mounted, which no amount of permission will help with.

The practical test takes a minute. Point the candidate at a directory known to be large but protected, and see whether it reports a plausible number, a zero, or an explicit statement that access was denied. The third answer is the one to hold out for. A tool that says nothing is not measuring the disk, it is measuring its own access rights and presenting the result as a disk report.

For shell work the same rule applies with different plumbing. A du run without sufficient rights prints permission errors to standard error and carries on totalling everything else, which means the number at the bottom is quietly wrong unless those errors were read. Redirecting them somewhere visible rather than discarding them is the difference between a measurement and a guess.

Axis two: how it counts

Three different numbers can honestly be reported for the same file, and which one a route uses decides whether its answer is relevant.

Blocks occupied is what du reports. For a file evicted to the cloud, that is close to zero. This is the right number when the goal is reclaiming space today.

Recorded size is what find -size and most graphical listings use. The evicted file reports at full weight. This is the right number when planning what a volume will hold once everything is brought back.

Shared blocks complicate both. APFS clones share their underlying storage, so summing per file sizes across a directory of clones produces a total larger than the volume can physically hold. Sparse files do the reverse, reporting a large size while occupying little.

There is one more counting question with a bigger practical effect than any of the above: whether packages are opened. A photo library, a video project, an application bundle. Each is a single item in the Finder and a directory tree on disk. A route that stops at the package boundary will report a hundred gigabyte library as one line, which is technically correct and useless, because the decision needs to know which parts inside it grew.

Axis three: what it can do after the list exists

Finding is the cheap half. The expensive half is acting on two hundred rows while making a judgement about each one, and routes differ enormously here.

The built in Storage screen deletes immediately, with a confirmation that says the action cannot be undone. Nothing reaches the Trash. That is appropriate for installers and unambiguous cache directories, and wrong for a session where mistakes are expected.

The questions to ask of any alternative are narrow and answerable:

• Does deleting route through the Trash, or erase in place
• Can an item be moved to another volume instead of deleted, in the same pass
• Does a record of what was removed survive the session
• Can the list itself be exported as text

The last one matters more than it looks. A list that can be saved is a list that can be reviewed tomorrow, diffed against next quarter's, or handed to a command. A list that exists only inside a window has to be acted on immediately or lost, which pushes toward hasty deletions.

There is a related question about scope of action. Some routes only operate on what they listed, which sounds obvious until a session where the right move is to delete a directory two levels above the file that appeared in the list. A view that can reveal an item in a folder window, so the surrounding directory becomes visible and actionable, removes a category of half decisions where something gets deleted because it was the only thing on screen.

Axis four: how often the answer is needed

A one time cleanup and a recurring audit are different products wearing the same label.

For a one time cleanup, nothing needs installing, nothing needs configuring, and the ability to repeat the process is worth nothing. Speed to first answer is the only axis that counts.

For a recurring audit, the requirements invert. The run has to be scriptable so it can happen without attention. The output has to be stored so this month can be compared against last month. And the comparison is the actual product: knowing that a directory grew by forty gigabytes since March is far more actionable than knowing it currently holds two hundred, because the first version identifies a process that is still running.

Scheduling changes the permission question too. A command run by hand inherits the rights of the person typing it. The same command run unattended runs under whatever context the scheduler provides, which is frequently more restricted, and the result is a monthly report that quietly omits the directories that matter most. Testing the scheduled run once and comparing its output against a manual run is a five minute check that prevents a year of misleading numbers.

Almost nothing keeps that history by default. A dated text file written by a scheduled du run is a crude implementation and outperforms most graphical alternatives on this axis, simply because the alternatives throw the previous state away.

Axis five: where the answer has to arrive

The last axis is about the next action rather than the measurement, and it is the one most comparisons omit.

If the outcome is reading a list and deleting a few obvious items, a window is the right destination. If the outcome is a bulk operation, moving three hundred rendered exports to an archive volume and rewriting a project reference, then the list needs to arrive as paths in a shell. A route that ends in a window forces that handoff to happen by hand, one selection and one path copy at a time.

Counting the trips is the quickest way to settle this. Between finding an item and finishing with it, how many times does attention move between a list, a folder window, a terminal and something used to look up what the file even is. When that count is high, the constraint is not measurement accuracy, and buying a better scanner will not move it.

The axes against the available routes

Route	Sees other volumes	Opens packages	Reversible delete	Repeatable	Hands off to a shell
System Settings, Storage	No, startup disk only	No	No, erases in place	No	No
Finder smart folder on size	Yes, if mounted	No	Yes, via Trash	Yes, saved condition	Path copy only
du and find	Yes, any mounted path	Yes	Depends on the command	Yes, scriptable	Already there
Disk usage application	Usually	Usually	Varies by product	Rarely	Rarely
File manager with a terminal	Yes	Yes	Yes	Yes	Yes

Two columns in that table deserve more weight than the others when the rows are close. Reversible delete decides how fast a session can move, because an irreversible route forces a pause at every uncertain item, and uncertain items are the majority. Handing off to a shell decides whether the work after the list is one command or three hundred manual selections. The remaining three columns are usually satisfied by several routes at once and rarely settle the choice on their own.

The Finder row is the one most often forgotten. A smart folder built with a file size criterion, scoped to a mounted volume, gives a live sorted list where deletion goes through the Trash and the condition can be saved to the sidebar for reuse. It costs nothing and covers a surprising share of the job, and it is what remains available on a managed Mac where installing software is not an option.

Two situations where the decision is already made

Some machines do not need the full analysis.

On a managed or restricted Mac without administrator rights, most of the table collapses. Software cannot be installed, Full Disk Access cannot be granted, and other accounts cannot be inspected. That leaves the Storage screen, a Finder smart folder, and whatever a shell can reach as the logged in user. Time spent comparing products is time wasted, and the smart folder deserves the attention instead.

On a machine where the growth is concentrated in one project directory, which is common for development and for video work, the answer is a scheduled du against that directory with the output appended to a dated file. The whole problem is one directory tree and a trend, and the comparison over time is the entire value. Anything graphical is an ornament on top of that.

What to change first

Write the four line description of the disk layout before reading another comparison, because it eliminates most of the options without any further research. Then run one measurement today, from the Storage screen or from du -h -d 1 ~, to find out whether this is a one time cleanup or a recurring audit, since the two lead to different answers on every axis above. If the count that comes out high is the number of trips between a list, a folder and a terminal, the axis that matters is the last one, and the comparison of file managers covers it, with Atriens built around keeping those steps in one window.