Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel!munnari.oz.au!network.ucsd.edu!sdd.hp.com!usc!elroy.jpl.nasa.gov!ucla-cs!ucla-mic!scott From: scott@pita.cns.ucla.edu (Scott Burris) Subject: CD-ROM bug and fix (386bsd) Message-ID: <1992Aug10.135220.3884@mic.ucla.edu> Nntp-Posting-Host: pita.cns.ucla.edu Reply-To: scott@pita.cns.ucla.edu (Scott Burris) Organization: UCLA Campus Network Services Date: 10 Aug 92 13:52:19 PDT Lines: 67 There is a kernel bug in the isofs code which causes files to disappear from CD-ROM filesystems on rare occasions. For the tale of woe and the kernel patches, read on. I've been working with an X11R5 CD-ROM trying to build a source code tree of symbolic links to it, so I can kick most of the X11 source off my hard disk. The CDROM comes with a program to create the links to the CDROM, at the same time mapping the real filenames to the ISO filenames. It does this by consulting a file called "file.lst" in each directory. Well it occasionally complained that it couldn't find certain files on the CDROM. Sure enough, there were some files listed in "file.lst" which didn't exist on the CD-ROM. Initially I just thought it was a problems with the CD-ROM distribution, but by doing an "od -c" on dot, I was able to look at the raw directory data and saw that the missing files were there. It turns out that the infamous "off by 1" problem hit two places in the isofs code. There is a check to see that a directory entry doesn't span more than one physical block -- if so, that's an error. Well if the directory entry just happened to end at the last byte of the block, the kernel throught it crossed into the next block and bailed out assuming the CD-ROM wasn't following the standard. The effect is that not only can't you access the file associated with this directory entry, you also can't see any files or directories located after that entry. As I said, this is relatively rare, because a series of directory entries must fit perfectly into a 2048 byte CD-ROM block for this to trigger. I only saw about seven instances of the problem in 500MB of sources. The patches fix support for readdir() (which is why the files don't show up with ls) and open() (why you can't get the file even if you explicitly use its name). Diff's follow: *** /usr/src/sys.dist/isofs/isofs_lookup.c Sat Aug 1 12:05:29 1992 --- /sys/isofs/isofs_lookup.c Mon Aug 10 08:17:14 1992 *************** *** 239,245 **** /* illegal entry, stop */ break; ! if (entryoffsetinblock + reclen >= imp->logical_block_size) /* entries are not allowed to cross boundaries */ break; --- 252,258 ---- /* illegal entry, stop */ break; ! if (entryoffsetinblock + reclen - 1 >= imp->logical_block_size) /* entries are not allowed to cross boundaries */ break; *** /usr/src/sys.dist/isofs/isofs_vnops.c Sat Aug 1 12:05:29 1992 --- /sys/isofs/isofs_vnops.c Mon Aug 10 08:17:16 1992 *************** *** 325 **** ! if (entryoffsetinblock + reclen >= imp->logical_block_size) --- 338 ---- ! if (entryoffsetinblock + reclen - 1 >= imp->logical_block_size) -- ---------- Scott Burris UCLA Campus Network Services cnetslb@oac.ucla.edu (213) 206-4860 - OR - scott@pita.cns.ucla.edu