> On Mar 5, 2021, at 4:11 PM, Boris Gimbarzevsky via cctalk
> <cctalk@classiccmp.org> wrote:
>
> Recovering data from disks was a lot easier 30 years ago when most
> filesystems had contiguous files and it was just a matter of finding file
> boundaries. Was very glad of this when accidentally wiped first 200 blocks
> of an RT-11 RK05 and just had to write a FORTRAN program to copy blocks of
> data and assign the files names.
Yes, RT11 has contiguous files. That actually made it rather unusual. For
example, while RSTS supports contiguous files that isn't the default and
because of disk fragmentation wasn't commonly used.
I was going to describe how you could do recovery on RSTS file systems, when I
realized that it doesn't actually work at all. The file system is designed to
allow you to piece it back together if some entries are corrupted. As an
extreme example, in the new (RDS 1) file structure, you could wipe out the MFD
-- the root directory of the file system -- and almost certainly put it back
together by scanning the disk for the GFDs -- the second level directories,
which are tagged with a magic number that allows them to be found easily.
On the other hand, if you delete a file there is nothing left in the file
system metadata to tell you about its previous existence. While the 8-word
blocks that make up directory entries only need two leading 0 words to be
considered "free", it turns out the file system code actually zeroes all the
entries in their entirety when deleting a file. So you can try to reconstruct
a file from free space, if you're lucky enough to be able to find its pieces
and connect them in the right order, but there isn't anything left of the
metadata (name, time stamps, etc.) Yes, that could have been left around, and
I'm actually somewhat puzzled about why it was done that way; it looks like
early versions (V4A at least) just zero the minimal 2 words which would leave
you half a file name and other stuff, not to mention 6/7th of the file data
pointers.
paul
