[TUHS] Early non-Unix filesystems?

[clemc@ccc.com (Clem Cole)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3698 bytes --]

Arrrgh hit send too soon...  sorry about that...

If you look at the two code snippets...look at the second parameter to
mknod.   Note how for mkdir.c they are setting the directory bits (040777) and
in the mknod command they are setting special type (060666 for blocked) and
( 020666 for character) and also then adding in the 3rd parameter the value
to be placed in the special file. That is to say, directories do not have
major/minor numbers. They only differ from regular files in having the
040000 bit turned on, but when that is turned on, the kernel can interprets
contents. However if you open and read them, they look like regular files,
and you are just not allowed to write them.

Clem

On Tue, Mar 22, 2016 at 8:54 PM, Clem Cole <clemc at ccc.com> wrote:

>
> On Tue, Mar 22, 2016 at 1:21 AM, shawn wilson <ag4ve.us at gmail.com> wrote:
>
>> Is that the last Unix that had a major number for file system objects? I
>> hadn't run into this but, thinking about it, it's kinda smart (probably
>> slower than specific execve kernel calls but still cool).
>
>
> ​I'm trying to parse your question a little and I think you may not quite
> understand how “pre-BSD 4.2” UNIX systems worked.
>
>
>
> In V7 the file system call works such that mknod(2) is used to create
> special files and directories, it does it a little different than you
> realize.  Generally, there is no need to use it to create a regular file,
> although you could.   To wit the man page says:
>
>
>
> SYNOPSIS
>
> mknod(name, mode, addr)
>
> char *name;
>
>
>
> DESCRIPTION
>
> *Mknod* creates a new file whose name is the null-terminated string
> pointed to by name.  The mode of the new file (including directory and
> special file bits) is initialized from mode. (The protection part of the
> mode is modified by the process's mode mask; see umask(2)
> <http://www.unix.com/man-page/v7/2/umask/>). The first block pointer of
> the i-node is initialized from add. For ordinary files and directories addr
> is normally zero.  In the case of a special file, addr specifies which
> special file.
>
>
>
>
>
> If you look at the code in mkdir.c (V7 mkdir.c source
> <http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/mkdir.c>)
> you see that what is being done is a mknod with addr=0 is being called and
> then the two links.
>
>
>
>
>
> . . .
>
> if ((mknod(d, 040777, 0)) < 0) {        fprintf(stderr,"mkdir: cannot make
> directory ­%s\n", d);
>
>       ++Errors;
>
>       return;
>
>  }
>
> chown(d, getuid(), getgid());
>
> strcpy(dname, d);
>
> strcat(dname, "/.");
>
> if((link(d, dname)) < 0) {
>
>       fprintf(stderr, "mkdir: cannot link %s\n", dname);
>
>       unlink(d);
>
>       ++Errors;
>
>       return;
>
> }
>
> strcat(dname, ".");
>
> if((link(pname, dname)) < 0) {         fprintf(stderr, "mkdir: cannot link
> %s\n",dname);
>
>       dname[strlen(dname)] = '\0';            unlink(dname);
>
>       unlink(d);
>
>       ++Errors;
>
> }
>
>
>
> Where as creating special files did mess with the “special file” bits in
> the mode.
> ​ ​
> If you look at the code in mknod.c (V7 mknod.c source
> <http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/mknod.c>):
>
>  . . .
>
> if(*argv[2] == 'b')
>
>       m = 060666; else
>
> if(*argv[2] == 'c')
>
>       m = 020666; else
>
>       goto usage;
>
> a = number(argv[3]);
>
> if(a < 0)
>
>       goto usage;
>
> b = number(argv[4]);
>
> if(b < 0)
>
>       goto usage;
>
> if(mknod(argv[1], m, (a<<8)|b) < 0)
>
>       perror("mknod");
>
> ​
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160322/7cc61b2b/attachment.html>