Thanks, mkdir actually seems to go back to V4.

Also, V4 was the first to have the kernel in a 'high level language' C, from the V4 tree,

The files in nsys/ come from nsys.tar.gz, which was donated by Dennis Ritchie. This is a version of the kernel quite close to that released in Fourth Edition, but without pipes. Dennis Ritchie writes:
 
This is a tar archive derived from a DECtape labelled "nsys". What is contains is just the kernel source, written in the pre-K&R dialect of C. It is intended only for PDP-11/45, and has setup and memory-handling code that will not work on other models (it's missing things special to the later, smaller models, and the larger physical address space of the still later 11/70.) It appears that it is intended to be loaded into memory at physical address 0, and transferred to at location 0.

The efforts behind the PDP-7 file system were quite tedious and was a general directed graph, only word addressable which meant lack of path names as it ignored null chars, the link call being used to link directories together which is where dd arises as the precursor to .. today. The required files for the user was just linked in together in their dirs. 

Quoting from DMR's Evolution of the Unix Time-sharing system,

So that every user did not need to maintain a link to all directories of interest, there existed a directory called dd that contained entries for the directory of each user. Thus, to make a link to file x in directory ken, I might do

ln dd ken ken ln ken x x rm ken
This scheme rendered subdirectories sufficiently hard to use as to make them unused in practice. Another important barrier was that there was no way to create a directory while the system was running; all were made during recreation of the file system from paper tape, so that directories were in effect a nonrenewable resource.

No mkdir/mknode while the system was running, the whole file system had to be recreated from the paper tape each time! Thank DEC for the PDP-11. And of course, no pipes until '72. Earlier parent had pondered on the write permissions required to execute programs, this below explanation from the paper might help.

Another mismatch between the system as it had been and the new process control scheme took longer to become evident. Originally, the read/write pointer associated with each open file was stored within the process that opened the file. (This pointer indicates where in the file the next read or write will take place.) The problem with this organization became evident only when we tried to use command files. Suppose a simple command file contains

ls who
and it is executed as follows:
sh comfile >output
The sequence of events was

1) The main shell creates a new process, which opens outfile to receive the standard output and executes the shell recursively.
2) The new shell creates another process to execute ls, which correctly writes on file output and then terminates.
3) Another process is created to execute the next command. However, the IO pointer for the output is copied from that of the shell, and it is still 0, because the shell has never written on its output, and IO pointers are associated with processes. The effect is that the output of who overwrites and destroys the output of the preceding ls command.

Solution of this problem required creation of a new system table to contain the IO pointers of open files independently of the process in which they were opened. 
 



On Mon, Oct 21, 2019 at 5:28 PM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:
    > From: Abhinav Rajagopalan

    > I only now realized that only mknod existed, up until a long time, only
    > later on with the GNU coreutils did mkdir as a command come into
    > existence.

Huh? See:

    https://minnie.tuhs.org//cgi-bin/utree.pl?file=V6/usr/man/man1/mkdir.1

(And probably before that, that was the quickest one to find?)

Maybe that was a typo for 'mkdir as a system call'? (I recall having to do a
fork() to execute 'mkdir', back when.) But 4.2 had mkdir().

       Noel



--

Abhinav Rajagopalan