Recursion list for rm -R in find

In the following command:

find / -ctime +3 -exec rm -R {}\;

how is the recursion list built for the actual rm ?

F'rinstance; I had a case where a user typed this as root using '/' instead of '.' so everything in the root level was going to be traversed. They hit <ctrl>C before too much was deleted but this leaves me with the task of figuring out what was deleted. The only files I am positive that were removed were from /opt and I haven't found anything missing from /bin

So, how does the kernel decide what directories get hit first since it doesn't appear to be alphabetical?

Oh boy. That F'rinstance caught me off guard. :eek: Reminds me of the public service announcement that shows at root's log in in SUSE.

I don't have an answer for you, but I've always been curious. I've thought it was alphabetical before . . . but always get frustrated when batch file operations never finish at Z. I thought I noticed "find" going roughly alphabetical along equal directory depths (I know it focuses on lower depths first), starting with lower-case and then upper - but I know it's not that entirely either - I really don't know. It has to be completely predictable though whether it's defined explicitly in the code or not . . . I'd love to see someone shed some light on it.

find finds things in arbitrary order, just the order they're stored in the directory entries on disk -- which is completely arbitrary. It's very difficult to say where this command started.

1 Like

I'm not sure what functions the rm command uses but I used to use readdir() and remove() in my old C programming days I had to start with an array or linked list and I usually started it with a bubble sort, which meant alphabetically. I was hoping to catch someone who might have some insight on how rm is coded. Then again, it's probably different depending on the OS. BTW, this issue is with AIX.

As Corona688 already said, the order in which rm processes files found in a directory is unspecified. All implementations of rm that I've seen will process them in the order that you would see if you used the command:

ls -f

for each of the operands that find passes to rm. I suppose some implementation of rm could waste time sorting its operands, but most UNIX systems don't want reduce performance by performing unneeded functions before calling a function equivalent to unlink() or rmdir() depending on the type of the file being removed.

But, the important thing (if you don't want to destroy your system) is to kill any command that tries to recursively remove files from root as soon as possible!

1 Like

Thanks Corona688 and Don Cragun. I never thought about the wasted resources of processing files in a specific order. :wink:

Makes sense though since we should be accountable for our own use of rm without prompting. I too have been caught in the, "Oh crap!" <ctrl>C myself.