goes to a fair degree of trouble to enable something like this to be safe: cd /tmp && find . -mtime +7 -delete It removes both files and directories. It does not attempt to remove immutable files (an earlier version I showed to a few people did a chflags and tried to blow away even immutable files. Too risky..) It is thought to be safe because it forces the fts(3) driven descent to only do "minimal risk" stuff. specifically, -follow is disabled, it does checking to see that it chdir'ed to the directory it thought it was going to, it will *not* pass a pathname with a '/' character in it to unlink(), so it should be totally immune to symlink tree races. If it runs into something "fishy", it bails out rather than blunder ahead.. It's better to do that if somebody is trying to compromise security rather than risk giving them an opportunity. Since the unlink()/rmdir() is being called from within the current working directory during the tree descent, there are no fork/exec overheads or races. As a side effect of this paranoia, you cannot do a "find /somewhere/dir -delete", as the last argument to rmdir() is "/somewhere/dir", and the checking won't allow it. Besides, one would use rm -rf for that case anyway. :-) Reviewed by: pst (some time ago, but I've removed the immutable file deletion code that he complained about since he last saw it)