Is there a way to find a maximum depth of given directory tree? I was thinking about using find with incrementing maxdepth and comparing number of found directories, but maybe there is a simpler way?

  • 1
    Is depth how many folders down from the / folder you are? Jun 6, 2017 at 7:16
  • no, it is depth under the current folder
    – ts01
    Jun 6, 2017 at 7:19
  • 1
    So are you trying to work out how many folders are under the, for example, /home directory? Jun 6, 2017 at 7:20
  • here you go : stackoverflow.com/questions/4329369/… (Recursive Function to Return Directory Depth of File Tree ) Jun 6, 2017 at 7:24

3 Answers 3


One way to do it, assuming GNU find:

find . -type d -printf '%d\n' | sort -rn | head -1

This is not particularly efficient, but it's certainly much better than trying different -maxdepths in turn.


Try this, for example trying to find max depth of tree under /, using

find / -type d

will give every directory under / irrespective of depth. So awk the result with / as delimiter to find the count, and count-1 would give max depth of tree from /, so the command would be:

find / -type d | awk -F"/" 'NF > max {max = NF} END {print max}'

Consider using updatedb and then locate. It performs really fast, as locate queries a database and it's much faster than asking for each file sepereately. updatedb is fast too, since it only updates the database with changes instead of creating it anew. The only drawback is that you may need root privilages to run updatedb by default, unless you make and preserve your own, user-space database.

Keep in mind that you may have newlines in your filenames, so that you need to be more careful about processing locate's output. Best to use null byte as a filename separator.

To sum it up:

updatedb && locate -0 "$(pwd)" | awk -v RS='\0' -F"/" '{print NF-1}' | sort -n | tail -n1

Thanks @sai sasanka for providing me with a perfect awk script.

  • updatedb runs find, so this can't be faster than running find just to extract the desired information. Jun 7, 2017 at 21:25
  • 1
    @Gilles it does not run find. From man updatedb "If the database already exists, its data is reused to avoid rereading directories that have not changed.". We are counting on reusing the database. Moreover, it can be seen as preprocessing which allows you to answer quickly for many queries. On my system with HDD drive updatedb took 2 seconds to finish, so it's really fast compared to other solutions. Jun 7, 2017 at 22:10
  • Using updatedb would be useful to make multiple queries, which is not mentioned in the question. Even so, updatedb records all files, which is a waste: for this, only directories are useful, so running and storing the output of find -type d would be faster. Jun 7, 2017 at 22:14
  • @Gilles from man updatedb "updatedb is usually run daily by cron(8) to update the default database.". Unless the OP has created and deleted many files in his filesystem it's much faster to update it and query the database than to run it again. And based on ext4 filesystem documentation it doesn't really matter if you apply -d flag or not. You must read the whole directory table anyway to check filetype flag of each file - and when reading this flag OS will load sequential bytes (with filename) to memory. Jun 8, 2017 at 12:25
  • Unless no directory has been created, moved or deleted since the last updatedb run, it's necessary to run updatedb again. It is possible to optimize find -type d to not read the whole directory table, and in particular to not read the content of a leaf directory: the hard link count on a directory indicates how many subdirectories it has. GNU find does not implement this optimization though. Jun 8, 2017 at 13:10

You must log in to answer this question.

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