steve@dartvax.UUCP (Steve Campbell) (05/15/86)
We have a large application package which appears to be driving a bug in 4.2's handling of directories. Unfortunately, we only have binary for the application, so we can't see exactly what the code is doing. But functionally, the application is removing a directory. So some system calls like rmdir or unlink are probably involved. The program runs setuid to root, BTW. The symptom of the alleged bug is a directory that gets corrupted instead of getting removed. Before the program runs, the directory is empty. Here is an annotated "od -H" of the directory, itself: /* inode namlrecl . inode */ 0000000 0000d017 0001000c 0000002e 0000c017 /* namlrecl .. */ 0000020 000201f4 00002e2e In case you don't have dir(5) handy, here is a formatted listing of the directory, done by a C program: .: ino = 53271, reclen = 12, namlen = 1 ..: ino = 49175, reclen = 500, namlen = 2 After the program runs, the inode field in the first entry is set to zero, and the reclen field is updated: 0000000 00000000 00010200 0000002e 0000c017 0000020 000201f4 00002e2e (My C program won't print this directory because readdir(3) immediately returns NULL.) Now this is just what dir(5) says should happen when the first entry in a directory block is being deleted, but in this case the entry is for ".", ie this is the first entry in the first directory block. Further, the directory is NOT unlinked and its parent's entry for it is intact, too. But 4.2 doesn't like that directory! You can't rmdir it; if you cd to it and then type pwd, you get "/"; and worst, fsck rejects the directory, claiming that "." is missing. The only way to fix things is either to use clri and fsck or to write a C program that does an unlink system call on the directory. My bug lists have nothing like this in them. If anyone knows about this one, please let me know. Thanks. -- Steve Campbell steve@Dartmouth.EDU dartvax!steve