the origin of mkdir(2) (was: [PATCH v1 00/21] man/man2/*: Update history of syscalls H-M)

["G. Branden Robinson" <g.branden.robinson@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1674 bytes --]

Hi Seth,

At 2026-01-26T12:28:10+0000, Seth McDonald wrote:
> This set updates the history of system calls H to M.
> 
> While I have been thorough with my research, I would encourage those
> interested to double-check that my edits make sense given the listed
> sources.  Particularly for linkat(2), SEEK_DATA/SEEK_HOLE, mkdirat(2),
> and mincore(2), since they took significantly more time and research
> than other functions.

I thank you for this work!  I could not have told you that mkdir(2)--
the system call--arrived in Unix as late as 4.2BSD.  My first thought
was, "that can't be right".  My second was, "ah, that must be when Unix
got rid of the 14-character limit on file names".

(Traditionally in Unix, a directory was a plain file of 16-byte
entries--a 14-byte `char` field for the file name, which was not
null-terminated if of maximum length, and a 2-byte `int` for the file's
inode number.  This design kept the system call interface narrow.  It
also, if I understand the war stories correctly, could lead to horrible
problems, like users open(2)ing directories belonging to themselves and
trashing them with sloppy code, or introducing cycles into into the
graph of the file system by creating hard links to directories.[1])

And sure enough, history appears to record that the Berkeley FFS ("fast
file system") came in with 4.2BSD as well.

https://www.oreilly.com/openbook/opensources/book/kirkmck.html

Regards,
Branden

[1] This was such an unthinkable and invalid situation that, again AIUI,
    that rather than being flatly prohibited by the kernel, only root
    was allowed to create hard links to directories.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]