Finding large files not working: what to check, in order

A large file sweep that fails rarely fails loudly. It returns a list. The list looks reasonable. Then the totals do not match the free space, or a file that should obviously be at the top is missing, or deleting fifty gigabytes moves the free space indicator by almost nothing. Nothing errored, so there is nothing to search for.

The useful way to approach this is not to swap tools. It is to work out which of the four numbers involved is lying, because there are exactly four, and each one fails for a different reason. The four are: the size a file reports, the space a file occupies, the number of files a scan can see, and the free space on the volume. A sweep that disagrees with reality is a disagreement between two of those.

The four numbers, and what each one actually measures

Before diagnosing anything, it helps to separate measurements that get used interchangeably in most write-ups.

Number	Where it comes from	What it counts
Logical size	ls -l, the Finder info panel	Length of the file content
Disk usage	du with no flags	Blocks the file actually holds
Apparent size	du -A	Content length expanded, ignoring compression
Free space	df, the Finder status bar	What the volume reports as available

On a filesystem without compression, cloning or cloud eviction, all four line up and none of this matters. On APFS with iCloud Drive turned on, which describes most current Macs, they routinely disagree by orders of magnitude. Every symptom below is a specific case of that disagreement.

One practical note before starting: pick df as the reference for free space and do not switch. The storage pane in System Settings updates on its own schedule and is the source of a good share of the reports that deleting changed nothing. Raw kilobytes from df, taken before and after, will not lie to you about a delta.

Symptom: the list totals far more than deleting recovers

This is the most common one and it has nothing to do with the scanning tool. APFS shares the underlying blocks when a file is copied. The Finder's Duplicate command does this. So does cp -c. The copy is a fully independent file as far as naming, dates and editing go, and it becomes genuinely separate data only when something writes to it.

A scan counts both copies at full size, because from the directory's point of view there are two files of that size. Measured on a volume where nothing else was running, creating a 500 MB file reduced free space by 529,676 KB. Cloning that file reduced free space by a further 1,076 KB. A recursive size total on the folder then reported 1.0 GB.

So the list says one gigabyte. The disk gave up roughly 517 megabytes. Neither number is wrong. They answer different questions.

The test takes ten seconds: note free space, delete one of the pair, check free space again. If it barely moves, the two were sharing blocks and the total was never real. This matters most when planning, because working backwards from a list total to decide what to delete will always come up short of the target.

Symptom: a file that should be huge is absent from the results

The inverse case. A file known to be several gigabytes never appears, no matter how the threshold is set.

This is what iCloud Drive's Optimize Mac Storage does. Content is evicted from local disk while the name, dates and size metadata stay behind. Apple describes the result plainly: files stop occupying space on the Mac, and the originals download again when needed.

The measurement on one such file: logical size 5,409,971 bytes, disk usage 0, apparent size 5,284 KB. All three are correct descriptions of the same file.

Which means a sweep built on disk usage drops it entirely, and a sweep built on logical size lists it near the top as a multi-megabyte candidate that will free nothing when deleted. Both behaviours confuse people, and both are the tool reporting honestly.

These files are identifiable. ls -lO shows a dataless flag on them. To list them in bulk, find accepts -flags +dataless. Once they can be named, the decision is easy: exclude them from a sweep aimed at reclaiming space, because there is no space in them to reclaim.

Symptom: the scan finishes fast and finds suspiciously little

When a terminal scan of the home folder returns far fewer results than expected, the first suspect is permissions rather than the command.

macOS protects Mail, Photos, Messages, Safari data and backups behind Full Disk Access. A terminal without that grant hits a permission denial on each protected directory. The scan does not stop. It skips, and it writes the denial to standard error.

That last detail is what makes this invisible. The widely copied habit of appending 2>/dev/null to suppress noise also suppresses the evidence that half the home folder was never read. Photos libraries and mail stores are frequently among the largest things on a Mac, and their absence reads as good news rather than as a failed scan.

While diagnosing, drop the error suppression. If permission denials appear, grant Full Disk Access in System Settings under Privacy and Security, restart the application, and run the scan again. A scan is only trustworthy once the range it covered has been confirmed, not just the results it printed.

Symptom: search results and a direct scan disagree on the count

The Finder's search and a saved smart folder query the Spotlight index. find walks directories as they are right now. These are different data sources and they are expected to diverge.

Measured on one machine with an identical size threshold: in the downloads folder, the index returned 39 matches and the direct walk returned 36. The index was ahead, holding entries for files already deleted. In the library folder, the index returned 73 and the direct walk returned 139. Here the index was behind, because parts of that tree are outside what it covers.

There is also a speed difference worth knowing about, since it explains why the index is tempting. The same downloads query took 0.09 seconds through the index and 1.00 second walking the directory. Across a whole volume that gap widens considerably.

The workable split is to use the index while narrowing down, because speed matters and precision does not yet, then switch to a direct walk before deleting anything, because precision matters and speed does not. mdutil -s will report whether a given volume is indexed at all, which settles the question quickly when a whole external drive turns up empty. The trade-offs between index driven and scan driven tools are laid out in the comparison with other file managers.

Symptom: the biggest item in the Finder is not a file at all

A related mismatch shows up when the Finder's view and a command line total point at different things entirely, and it comes from how macOS presents bundles.

A photo library, an application, a Logic project and a Final Cut library are all directories that the Finder draws as a single item. Opening one requires a deliberate action. A recursive scan has no such convention and descends straight into them, so the same 80 GB photo library appears as one row in the Finder and as several thousand rows in a terminal listing. Neither view is wrong, but a threshold applied per file will now match none of the contents, because individually they are small.

Disk images add a second version of the problem. A sparse image or a sparse bundle grows as data is written into it and, depending on type, does not shrink when files inside are deleted. From outside, the image is one very large file whose size reflects the high water mark rather than current contents. Deleting things inside it frees space within the image and nothing on the host volume. Compacting the image is a separate operation.

The practical handling is to treat bundles and images as units. Decide whether the whole photo library moves to an external drive, rather than hunting inside it for individual large items. When a scan produces thousands of rows from one directory, that is usually the signal that a bundle has been entered and the question should be asked one level up.

Symptom: everything was deleted and free space did not move

Three layers sit between deleting a file and the volume reporting more room, and they fail in that order.

The Trash is first. Deleting in the Finder moves the file inside the same volume. Nothing is recovered until the Trash is emptied, and external drives keep their own hidden Trash, which has to be emptied per drive.

Local snapshots are second. Time Machine writes a local copy when the backup destination is not attached. While a snapshot exists, the blocks belonging to files it captured stay allocated regardless of whether the visible file was deleted. Run tmutil listlocalsnapshots / to see them. An empty result prints only the heading, which is the answer you want.

Open file handles are third. A process holding a deleted file keeps its blocks allocated until the process exits. Quitting the likely application and re-measuring with df resolves this one. Long running processes are the usual culprits here: a video editor with a project still open, a virtual machine, a database left running from a week ago. The file disappears from every listing while its blocks stay spoken for, which is why this case is so easy to mistake for a broken delete.

There is a fourth layer that is less of a failure and more of a design decision. macOS keeps a reserve it can release under pressure, and that reserve is folded into the available figure. Free space can therefore appear stable across a deletion simply because the system rebalanced what it was holding. Comparing raw kilobytes before and after, rather than reading a rounded gigabyte figure in a settings pane, is what makes a change of a few hundred megabytes visible at all.

Checking those three in order separates "the delete did not work" from "the delete worked and the number has not caught up yet", which are different problems with different fixes.

Why this particular sweep takes so long to diagnose

Every check above requires moving between a list of files and a place to run a command against one of them. Look at the list, inspect an attribute, measure free space, delete one thing, measure again. When the list lives in one application, the commands in a second, and the reference material in a third, a single hypothesis costs several context switches, and there are five hypotheses.

Keeping the folder view, the shell and the reference in one window collapses that loop, which is the argument behind the feature set here. For a scan that runs long, checking progress from elsewhere is covered under From iPhone and iPad. Specific edge cases are listed in the FAQ.

What to change first

Record free space with df, delete exactly one suspect file, and record it again. That single measurement splits the five symptoms roughly in half, because it immediately tells you whether the problem is in what the tool counted or in what the disk released. Diagnose from there rather than from the list, and consider Atriens if the checking loop itself is the slow part.