frankb@usource.UUCP (Frank Bicknell) (07/20/89)
[ For those who didn't see it or didn't care at the time: a day or so ago, I posted an article about rm -r performing weird rituals and not doing what one would expect. ] After a bit of head scratching, I decided to see what the file /bin/rm looks like from the distribution disk. After taring it off into /usr/tmp, sum yielded different checksums! Sure enough, a hex dump of both files and a subsequent diff of the results yields this mysterious piece in the bad copy (diff was run as 'diff good_rm bad_rm': 542,554c542,547 < 2200 64 69 72 65 63 74 6f 72 79 20 25 73 3a 20 3f 20 directory %s: ? [ good hex dump omitted. You can run it on yours if interested! Suffice to say that it is in the string storage area. ] < 22c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ --- > 2200 44 49 53 4b 20 54 41 42 4c 45 53 00 00 00 00 00 DISK TABLES..... > 2210 f1 e5 00 f0 f1 e5 00 f0 02 02 02 02 02 02 02 02 ................ > 2220 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 ................ > * > 2310 02 02 02 02 02 02 02 02 00 00 00 00 00 00 00 00 ................ > 2320 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Now where on earth did this little blob come from!? The modification dates of the two files are the same! What's more, a quick look at the level 9 backup of the root filesystem reveals that backup did not detect the inode mod date as having changed, either! This is most mysterious, folks! Has the operating system deposited a little piece of trash which happens to have landed in the middle of /bin/rm??? Why is this trash so coherent? Has anyone seen the pattern above somewhere else? Before I zap this inode, is there some way of telling where it is on the disk? Now I wonder if I should use that area at all... BTW... fsck reports no problems outside the normal POSSIBLE FILE SIZE ERROR stuff (not on this inode). We did have a rather mysterious controller or disk failure the other night which hasn't seemed to have any other effects (something froze with HD light on: no panics, no system error messages). The system had been apart the previous day testing a new controller _on another HD_, so I attributed it to a connector or card not quite seated right. Xenix 2.3.1, 80386. WD1003 controller, Seagate 4096 and MiniScribe something-or-the-other. Signed, Most Mystified. -- Frank Bicknell UniSource; 1405 Main St, Ste 709; Sarasota, FL 34236 attctc!usource!frankb || frankb@usource.UUCP