find Cheatsheet - Linux File Search Reference

SymptomAfter the delete some files are still there, or directory contents that should have been kept got wiped.

Cause-exec and -delete modify the filesystem during the walk, so an over-broad pattern removes files with no way back.

FixSwap the action out first, run a read-only combination such as find . -name "*.txt" -print to list the hits, check them one by one, then put -delete back.

SymptomOn a large tree the command prints nothing for a long time and looks hung.

Causefind recurses from the start point to every leaf and reads each directory on the way down, which gets expensive purely by directory count; nothing is wrong with the disk.

FixShrink the scope with find . -maxdepth 2 -name "*.log", prune directories you do not need, then widen the conditions gradually.

SymptomThe same file appears in one run and is missing from the next.

CauseThe tree keeps changing while find walks it - an application writing logs, a build writing artifacts - so find is reading a directory tree in motion.

FixNarrow the scope to a concrete directory with find . -maxdepth 2 -name "*.log", or wait for writes to stop; do not take a full count during a heavy write period.

SymptomRunning -exec one match at a time on a big tree takes minutes.

CauseThe per-match form starts a process for every hit, so with tens of thousands of matches the spawn and scheduling cost dwarfs the work the command actually does.

FixUse the batch form find . -name "*.log" -exec rm {} + to hand every path to a single invocation.

SymptomThe target clearly exists, yet find reports no such file or directory.

CauseWhen a pattern contains spaces or wildcards and is left unquoted, the shell expands it first into names in the current directory, so find never receives the original pattern.

FixQuote the pattern, as in find . -name "*.log", and make sure the relative form matches the walk start point.

SymptomAfter cleaning up with -empty the directory structure collapsed and the toolchain stopped starting.

Cause-empty matches empty files and empty directories alike, so removing empty build directories breaks anything that relies on that layout.

FixRestrict the sweep to regular files, for example find . -type f -empty -delete, which touches files only.

SymptomThe goal was to exclude node_modules and the whole result set came back empty.

CauseWhen -prune evaluates true it drops the whole branch; if it is not separated with -o it also swallows the matches that should have continued.

FixJoin the two sides with -o as in find . -name node_modules -prune -o -name "*.js" -print and confirm no grouping was rewritten around them.

SymptomThe permission count is off by an order of magnitude from what was expected.

Cause-perm 755 demands an exact match, so a single setuid bit or a different group field excludes the file, while -perm -u+x and -perm /o+w are contains and any-of tests with a far larger hit set.

FixDecide which relation you mean: exact with find . -perm 755, contains with find . -perm -u+x, or a loose sweep with find . -perm /o+w.

SymptomThe report mixes files and directories and looks like it double-counts.

CauseA search without -type returns directories too, and find . -type f and find . -type d walk the same paths, so merging the outputs without deduplicating repeats rows.

FixState the type explicitly, or keep non-directories only with find . ! -type d, and check for overlap when merging the two lists.

SymptomThe search for recently modified files returns nothing.

CauseThe sign on a time test is easy to invert: -mtime -3 is within the last three days while -mtime +3 is older than three days, so a flipped sign lands the window in an empty range.

FixValidate the direction with find . -mtime -7 first, confirm there is output, then move to an older cut such as -mtime +30.