[TUHS] Re: Extracting files from various old dump/restore tapes

[Warner Losh <imp@bsdimp.com>]

[-- Attachment #1: Type: text/plain, Size: 1742 bytes --]

On Mon, Aug 22, 2022 at 11:55 PM Lars Brinkhoff <lars@nocrew.org> wrote:

> Warner Losh wrote:
> > So 60011 is OFS_MAGIC and 60012 is NFS_MAGIC. Both of these are
> > variants on UFS, but really old. And given they are at different
> > offsets, you'll likely need to reverse engineer the offsets used for
> > the platform's dinode.
>
> So anyway, it seems my best bet would be getting an old "restore" and
> hack it till it runs.
>
> Part of the problem is that there are hundreds of these images, so it
> would be a lot of work to examine them individually in emulated systems.
> A good first start to examine the content would be to just list the file
> names.
>

For V7 tapes, you can run the V7 binaries using apout with very little
effort.
This is a user-level emulation of a pdp-11 with the system calls for v5,
v6, v7 and
some of the BSDs. It's in the tuhs archives under
Distributions/Research/Dennis_v1/unix72/tools/apout.
I used it to extract files from V7 automatically that I used in the 2.11
back-patching-to-the-original-tapes
script I wrote.


> > Without more specific data it's hard to know if there's an extant
> > binary that can be run in emulation to read these tapes.
>
> The tapes are from MIT's "Tapes of Tech Square" collection.  Likely
> candidates include PDP-11 V7, 4.x BSD on VAX, and Sun workstations.  I
> suppose the latter would use the big endian format.
>

Very cool. I suspect if you want one tool for them all, you'll need to take
restore
and teach it to cope with multiple endians and word sizes... It's likely
not a huge
effort, but the restor code from V7 makes use of a lot of type-punning...


> There are also many variations of the tar and cpio formats, but I'm on
> firmer ground there.
>

Warner

[-- Attachment #2: Type: text/html, Size: 2602 bytes --]