dudek@harvard.ARPA (06/12/85)
Description: There is a minor bug in the mknod(2) system call in sys2.c. Mknod calls namei to parse the pathname, and then examines the inode pointer returned to see if the file already exists. If it does, then it returns the error EEXISTS. If it does not exist, then it goes ahead and tries to allocate a new inode, WITHOUT checking the error status from namei. If (for instance) part of the path does not exist, instead of returning ENOENT (No such file or directory), mknod goes ahead and tries to get an inode, more often than not resulting in a failed getfs() (trying to find the filesystem the non-existent parent lives on) and a return of ENOSPC (No space left on device). Repeat-by: Try "mknod /foo/tty00 c 1 0", (where /foo is some directory which does not exist) preferably from the console. You will get a kernel console printf of "No fs on dev #, #", and "No space left on device" from mknod(8). Fix: After the section of code in mknod() in sys2.c which ensures the return value from namei() is NULL, add the test: if (u.u_error) return; Exciting, no? At least I wasn't out of inodes like I thought at first. Glen Dudek harvard!dudek, dudek@harvard.ARPA, dudek%HARVUNXH.BITNET