Thanks for all your suggestions. What I finally did was restore the ".disk" files from a previous backup 'tar -xf ~/research-backups/backup-mu-0228.tar' under Linux then restored my backup copies of files using 'tar x0 backup.tap' under Unix v7. All is well now. Thanks Ken On Wed, Mar 1, 2023 at 11:19 AM Ron Natalie wrote: > You had adb? They hadn’t even released that when we were fixing > things up. If we had a mountable disk that got too corrupt to fix > using the tools, we usually wrote our own and fixed the disk (all our > packs in those days were pretty much RK05s) from a running sytsem. > > It was reqiured before you could come on the operations staff at my > college to be able to be quizzed on just how the (then version 6) > filesystem was layed out and what the possible corruptions were and how > to fix them. > > The original V6 filesystem was pretty ugly in that it wasn’t careful in > even trying to do operations in the right order so as not to lead to > hideous corruptions (duplicated blocks etc…). One of our summer > projects at the BRL when we were interning up there was that one of us > (not me) was to write an automatic disk fixer (I had a different > project). Bob never got too far with that. > > Clri was especially problematic as a tool. If you wanted to zap a node > that was a 0..0 (i.e., with a zero reference count AND not in any > directory referneces), it would irreverably write zeros over all of it. > We changed it to “clam” which only zonked the mode bits which if you > did it to the wrong inode, you could usually get back to some working > state. > > Running icheck and dcheck were standard on reboots. ncheck was pretty > darned slow and we used it mostly for hunting down file names for things > we knew were corrupted and relinking chunks of the filesystem that got > detached from the root. > > The world changed when we got better file system code and fsck. > > -- End of line JOB TERMINATED