Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site seismo.CSS.GOV Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!ucdavis!lll-crg!seismo!keith From: keith@seismo.CSS.GOV (Keith Bostic) Newsgroups: net.bugs.2bsd Subject: CSS/Harvard 2.9BSD bug report #10 Message-ID: <404@seismo.CSS.GOV> Date: Sat, 12-Oct-85 15:49:44 EDT Article-I.D.: seismo.404 Posted: Sat Oct 12 15:49:44 1985 Date-Received: Mon, 14-Oct-85 04:10:50 EDT Organization: Center for Seismic Studies, Arlington, VA Lines: 81 Keywords: sys/dir.h sys/user.h struct direct Subject: directory reading in 2.9BSD This is intended to be an explanation/discussion of the problems that people are having with various programs attempting to read directories in the CSS/ Harvard 2.9BSD. People have complained that the previous messages and the comments delivered with the source were unduly cryptic, so bear with me if I go into too much detail. As mentioned in the "gotcha" file delivered with the source, the "new" directory reading routines have been installed in the C library. This was intended to conform to the way 4.X does things and we had hoped that it would make porting various programs easier. Unfortunately, there are a few programs that really do need to know about the underlying directory structure, fsck and dump, for example. To get around this, we split the include file dir.h into two parts, one which had the defines for the old directory structure and one that had the defines for the new directory structure. Which part of it was actually included was dependent on whether or not the define "KERNEL" was set. Then, in programs that needed the old stuff, we surrounded the include statement for dir.h in the following fashion. #define KERNEL #include #undef KERNEL As has been pointed out to me in *great* detail, this was Evil because it assumed that a program would never need to use *both* sets of directory reading includes. It starts to get nasty when you realize that user.h (the user structure) has a directory structure in it, u_dent. This causes all sorts of things to break because programs that include user.h have to include dir.h to satisfy the directory structure requirement. Since they don't define KERNEL before they include it, they get the wrong size directory structure and therefore think that the user structure is the wrong size. This was the problem with ps. There are numerous fixes to the this particular problem. Fix one, the easy one. For the debonair person-about-town who doesn't particularly care to muck about the kernel and various applications. Whenever you come across a program that includes user.h and attempts to read the user structure, make sure that it defines KERNEL before it includes dir.h. If it later also uses the directory reading routines, split that module into a separate file and include dir.h again, this time without defining KERNEL. Any programs that are reading the actual device, not the directory file, should define KERNEL before including dir.h. Other programs should be converted to use the new directory reading routines. If you choose not to convert them, defining KERNEL before including dir.h will probably make them work. This approach should fix any problems you run into with the programs on the CSS/Harvard 2.9BSD tape. Obviously, it won't fix all possible problems. Fix two, the "interesting" one. For the home-handyperson type. Move the kernel directory structure into user.h and change its name. Below is what I've put in my user.h. /* * The V7 directory structure, to be used by the kernel and programs that * need to read the file system directly. */ struct kerdir { ino_t kd_ino; char kd_name[MAXNAMLEN]; }; ... struct kerdir u_dent; /* current directory entry */ Then, remove the includes for dir.h from the entire kernel. (There are about 20 incidences.) Then, in fsck.c, mkfs.c, ncheck.c, dcheck.c, dump/*.[ch], dumpdir.c, ps.c, adb/*.[ch], w.c, restor.c and the kernel, change all occurrences of "d_ino" to "kd_ino", "d_name" to "kd_name", and "struct direct" to "struct kerdir". Be careful when you make these changes, I don't remember any nasty things like variables called "xd_ino", but I may have forgotten them. Remake the dependency lists in all the makefiles. Remake the programs and the kernel. Obviously, I prefer the second fix; it's cleaner and allows most programs to ignore the differences between the two directory structures. It won't impact on our effort to be 4.X compatible, these programs are never going to be 4.X compatible anyway. On the other hand, the first fix is certainly easier; you'll get the second fix when you get our next tape. --keith