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 <ron@ronnatalie.com> 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