I've always kind of wondered why rmdir(2) only deletes empty directories. (I suppose it could be simply to keep the recursive directory traversal logic out of the kernel.) One can usually just recursively delete directories so this doesn't matter but I ran across a situation where it does actually matter that rmdir only deletes empty directories that I hadn't considered before.

If directory /containing is writable by user u and directory /containing/private is not writable by user u, then u can delete /containing/private only if /containing/private is empty.

This kind of feels like it's a security/access control choice. Does anyone know if this scenario was an explicit consideration when the rmdir system call was being designed? (The macOS man page suggests that rmdir(2) appeared in 4.2BSD.)

@stevecheckoway I strongly suspect that it’s historical. In particular: if rmdir(2) dates to 4.2bsd, how did one remove directories before that. The answer can be found by looking at the source to, e.g., v7 rmdir at https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/rmdir.c — it simply unlinked the directory. Only root could do that (and yes, rmdir(1) was setuid (and I think insecure against race conditions), but without good locking (and Unix didn't have good locking then) you could end up with a tree mess if non-empty.