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