POSIX ain't what you think it is....

The author states that the problem with POSIX is that it codifies errors. That is probably true, but I believe the author has not accurately relaying what POSIX has codified either. In particular, the case of making hard links to directories is exaggerated. I don't have access to the 1988 document at the moment, but the current version treats the issue as follows:

...If path1 names a directory, link() shall fail unless the process has appropriate privileges and the implementation supports using link() on directories...

So what does that mean? It says that IF the process is sufficiently privileged (traditionally running as root) AND the implementation elects to do so THEN it is not an error for a link to actually be created for a directory. Any program that actually wants to work properly on all POSIX system can NEVER require such an operation to work even if running as root. That's a pretty lukewarm endorsement of the functionality.

You might ask why it's even in there at all. The original UNIX systems (all version) had no atomic mkdir() system call. You used mknod() to make a TOTALLY empty directory and then used link() to create the standard . and .. entries in the newly created directory. The mkdir program was setuid root and if you wanted to create a directory from within a program
you had to do a fork() and exec() the program. Specifying link() in this way allowed UNIX versions which had traditionally made directories this way to get POSIX certification while in no way encouraging implementations of this type. Frankly, I think that was a good decision. Leniency for historical practice, but encouraging more reasonable implementations in the future. Users don't run their own programs as root so there was never any danger of people making directory loops to screw up your system.