I have a directory with a lot of files and subdirectories. I know there are a small number of large files contained somewhere within. What is a quick/easy way to identify one or more large files in a directory, including throughout all it's sub directories?

I tried this:

find . -printf '%s %p\n'|sort -nr|head
find: -printf: unknown primary or operator

and this:

find -type f -printf '%s %p\n' |sort -nr | head

find: illegal option -- t
usage: find [-H | -L | -P] [-EXdsx] [-f path] path ... [expression]
       find [-H | -L | -P] [-EXdsx] -f path [path ...] [expression]

and this:

find . -type f -printf "%s %p\n" | sort -nr | head -1
find: -printf: unknown primary or operator
  • 1
    As the liked questions answer suggests what does man find say – mmmmmm Aug 9 '20 at 12:15
  • Do you have an idea how "large" you are seeking? I assumed you really needed to search in a specific folder but if you just care about all large files you might drop the | grep part (or change it). In my case, mdfind reports results for 10k files in about three tenths of a second. – bmike Aug 9 '20 at 12:30
  • @bmike it would be great to find (say) the top ten largest. In this particular case I’m pushing to github, I know there are a few large files (data files) somewhere in the repo and want to avoid having to travel through manually – stevec Aug 9 '20 at 12:34
  • Odd - why not just let finder calculate all sizes and interact with size that way? You'll add a lot of processing but I'm sure someone will come around and help fix your syntax or logic errors in find. Worst case, you can make a quick list of all large files if that helps using spotlight. My solution isn't 100% what you ask, but it sidesteps common errors like spaces and file encoding issues and learning how to extract data from find – bmike Aug 9 '20 at 12:40
  • thanks @bmike it seems bash/zsh certainly has its complications around escaping, spaces etc. In my (scrappy) use case, I had a directory I wished to initialise in git and push, but I knew there were a small handful of large and unnecessary files I could remove beforehand, scattered and buried deep in subdirectories. I think I would use finder if I had to be very certain of things (since I wouldn't know all the gotchas of bash/zsh and file system conventions etc) – stevec Aug 9 '20 at 17:15

Here's an example using BSD find and stat-

find . -type f -exec stat -f '%z %N' {} + | sort -nr
  • Thanks @fd0. This did exactly what I was after. in my case it returned a few hundred results, so applied a technique on another answer to limit to top 10: find . -type f -exec stat -f '%z %N' {} + | sort -nr | head -n 10. Do you know if this approach has any issues handling edgecases like directories / files with spaces (or other special characters)? I am not sure how exactly it works but thought it could be handy knowledge for future reference if you know – stevec Aug 9 '20 at 17:22
  • 1
    @stevec There isn't a problem with stat because it is executed by find. Thus filenames are not subject to word splitting or globbing or any other shell meta-characters. Once the find's output goes thru the pipe to sort there are not any guarantees. I tested this with a group of filenames with shell meta characters and it performed well. – fd0 Aug 9 '20 at 18:13

I like spotlight better than crawling the filesystem for speed reasons. This doesn't directly report sizes so you can sort top 10, but you can quickly (fraction of a second) locate places where large files exist.

mdfind 'kMDItemFSSize > 2000000000' | grep "$(pwd)"

More options are on this thread. Add or remove zeroes or pick your size threshold for finding large files.

As to your syntax errors and other problems you'll face is handling spaces in files and directories, hence the " " around $(pwd) so you can quickly get in territory where you need to learn a bit more about shells, pipes, white space and escaping words / variables. Worst case, isolate each one element above so you can learn what the output of the find command is telling you and they layer back the filters / processing once you have valid results.

If all you are after cleaning large files and you don't need a script and want to learn that later. I recommend system information, storage management or Daisy Disk. Finder also can calculate all sizes well for me in preferences if you want to interact as you navigate.


BSD find (which is part of macOS) and GNU find (which is part of Linux distributions) use different options, so your examples won't work.

  • You can install GNU find via Homebrew (brew install findutils) and then use gfind to get GNU syntax/options
  • For a quick solution, du -a TOP-DIRECTORY | sort -r will work as well. It lists both files and directories though, so it won't easily work within a script
  • 1
    In zsh, you could use zsh's extended glob and list only files. Something like- du ./**/*(.) | sort -rn – fd0 Aug 10 '20 at 17:12

If you're looking for the largest file(s) in each directory and child subdirectories

Use the du command:

du -ah . | sort -nr | head -n X

Where X is the number of results you want. For example, if you want the top 25, substitute 25 for X. If you only want the largest file, use 1. It will list the output in "human readable format."

  • 1
    du also calculates directory sizes, so if you go with X=4 and the biggest file is more than 4 directory levels deep it may not even show up at the end. – nohillside Aug 9 '20 at 17:11
  • 2
    Running your suggested command with X being set to 1 or 25 on my Downloads directory, which has 642 items ranging between 0 bytes and over 5 GB, does not output the largest files in that directory! On. my system it outputs files in the 3 and 4 digit K range. You can not get the desired output sorting on human readable output using the -h option of the du command in a real world usage scenario such as this. The accepted answer works, where this one doesn't. – user3439894 Aug 10 '20 at 2:09

Do you need this for a script, or is a manual tool acceptable?

I find Disk Inventory X is outstanding for identifying large directories and files.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .