The specific errors were on two disks. 76/3, 77/7 and 78/5 on the "User 3" disk and 78/5 and 79/5 on "User 2". The program I was using to read the disks didn't report the kind of error, so I'll have to augment it to do so.
This is very concerning to me, so I though I'd take a closer look what's on the disks. It appears that the disks are much simpler than I'd though. The first two tracks (10k) is nothing at all. Then we have what appears to be a TAR file after that. So, it looks like, worst case, we have at most 5 files that are corrupted, and more likely only a couple. The distance on User 2 is only 5k, while the distance on User 3 is 11k. There's a good chance that there will just be one file that's affected.
If I wanted to try to extract these disks, there's another wrinkle. I thought a simple dd to remove the first 10k would do the trick. However, there's a snag. I read these in the physical mode. The RX-50s, at least as used on the Rainbow, have a sector interleaving starting with track 2. The actual sectors are labeled as 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 on the disk (that's the order I read them out in). However, it appears that these sectors correspond to 1, 6, 2, 7, 3, 8, 4, 9, 5, 10, so I'll have to write a stupid filter to de-interlace them. Otherwise TAR throws all kinds of fits.
Unix v7 Tar files, btw, have fixed 512-byte headers. Wasteful, to be sure, but great for data recovery. A quick grep from hexdump shows what's on the 'User 1' disk:
so there's lex, yacc, and several familiar filters. Transferring from the Rainbow is being super slow since I'm sending them via old-reliable KERMIT, so I've only looked at the first file.
00001400 2f 75 73 72 2f 61 64 6d 2f 00 00 00 00 00 00 00 |/usr/adm/.......|00001800 2f 75 73 72 2f 62 69 6e 2f 00 00 00 00 00 00 00 |/usr/bin/.......|00001c00 2f 75 73 72 2f 62 69 6e 2f 61 64 62 00 00 00 00 |/usr/bin/adb....|00009200 2f 75 73 72 2f 62 69 6e 2f 72 61 6e 6c 69 62 00 |/usr/bin/ranlib.|0000c600 2f 75 73 72 2f 62 69 6e 2f 63 61 6c 00 00 00 00 |/usr/bin/cal....|0000e000 2f 75 73 72 2f 62 69 6e 2f 61 63 00 00 00 00 00 |/usr/bin/ac.....|00010800 2f 75 73 72 2f 62 69 6e 2f 62 63 00 00 00 00 00 |/usr/bin/bc.....|00011400 2f 75 73 72 2f 62 69 6e 2f 64 6f 73 63 6f 70 79 |/usr/bin/doscopy|00014400 2f 75 73 72 2f 62 69 6e 2f 63 62 00 00 00 00 00 |/usr/bin/cb.....|00014600 2f 75 73 72 2f 62 69 6e 2f 64 63 00 64 63 00 2d |/usr/bin/dc.dc.-|00015000 2f 75 73 72 2f 62 69 6e 2f 63 61 6c 65 6e 64 61 |/usr/bin/calenda|00016c00 2f 75 73 72 2f 62 69 6e 2f 63 6f 6c 00 00 00 00 |/usr/bin/col....|0001a200 2f 75 73 72 2f 62 69 6e 2f 64 6f 73 00 00 00 00 |/usr/bin/dos....|00020400 2f 75 73 72 2f 62 69 6e 2f 64 65 72 6f 66 66 00 |/usr/bin/deroff.|00021e00 2f 75 73 72 2f 62 69 6e 2f 65 67 72 65 70 00 00 |/usr/bin/egrep..|00026a00 2f 75 73 72 2f 62 69 6e 2f 66 67 72 65 70 00 00 |/usr/bin/fgrep..|00027a00 2f 75 73 72 2f 62 69 6e 2f 67 72 61 70 68 00 00 |/usr/bin/graph..|0002be00 2f 75 73 72 2f 62 69 6e 2f 69 70 6c 6f 74 00 00 |/usr/bin/iplot..|00031a00 2f 75 73 72 2f 62 69 6e 2f 6c 65 78 00 00 00 00 |/usr/bin/lex....|00039e00 2f 75 73 72 2f 62 69 6e 2f 73 70 6c 69 6e 65 00 |/usr/bin/spline.|0003c400 2f 75 73 72 2f 62 69 6e 2f 6c 70 73 74 6f 70 00 |/usr/bin/lpstop.|0003f800 2f 75 73 72 2f 62 69 6e 2f 6d 34 00 00 00 00 00 |/usr/bin/m4.....|00042a00 2f 75 73 72 2f 62 69 6e 2f 6e 65 71 6e 00 00 00 |/usr/bin/neqn...|0004a600 2f 75 73 72 2f 62 69 6e 2f 6e 72 6f 66 66 00 00 |/usr/bin/nroff..|00054600 2f 75 73 72 2f 62 69 6e 2f 73 70 65 6c 6c 00 00 |/usr/bin/spell..|00054c00 2f 75 73 72 2f 6c 69 62 2f 74 6d 61 63 2f 74 6d |/usr/lib/tmac/tm|00055600 2f 75 73 72 2f 62 69 6e 2f 79 61 63 63 00 00 00 |/usr/bin/yacc...|
All in all, I'd say this is encouraging news. I'll transfer the other disks and see what's missing to see if it is worth trying to delve further into the missing bits or not. If nothing else, it means we can use whatever data we can for those 5 sectors and the reduced functionality may be almost nothing. And there's a chance we can get a second copy of the affected files from the boot disk or something.
No comments:
Post a Comment