2000-01-30-20:02:02 Bruce Sterling Woodcock:
Apparantly this is an issue with Solaris (root can unlink() an non empty directory).
It's not Solaris per se; it's been a standard UNIX-ism for a long time.
I agree with that, the ability to unlink a non-empty directory (requiring fixes at fsck time) has been a documented feature of Unix everywhere I've seen.
I think it was deemed necessary for fsck to work properly?
I don't think it is necessary for fsck, rather fsck was necessary to repair the damage after doing it.
In all my years I've only seen one lone case where unlinking a non-empty directory was a good idea; it was the way to undo damage cause by another bug (since fixed). Once upon a time there was an NFS server implementation (in SunOS 3.x in the mid-'80s, since fixed I'm sure) which allowed an NFS client to create a file with a "/" in the middle of a filename. The NFS client that tickled this was a Macintosh gateway, a gizmo called a Cayman Systems Gatorbox, that hooked up to an Appleshare net on one side and an NFS/IP/Ethernet on the other, and did high-level protocol conversion. In that setting, Mac users could create, delete, and otherwise correctly manipulate files whose names contained slashes on a Unix server. But on the server such a file couldn't be touched. The fix was to move everything else out of the directory, unlink the directory, recreate the directory, and move everything else back. And to be on hand to hand-hold fsck through the ugly repairs next time you rebooted.
I just occurred to me, maybe unlink-nonempty-directory was required for "mv dir1 dir2", back before rename(2). When was rename(2) added anyway?
-Bennett