From: krewat@kilonet.net (Arthur Krewat)
Subject: [TUHS] Determining what was on a tape back in the day
Date: Sun, 19 Nov 2017 13:35:58 -0500 [thread overview]
Message-ID: <055c3e7f-6da9-497d-149a-16f230f55391@kilonet.net> (raw)
In-Reply-To: <20171119174919.166D018C0F5@mercury.lcs.mit.edu>
When reading magtapes, or any tapes for that matter, I usually dd the
"files" on the tape into separate files on disk. This doesn't preserve
the actual blocking factor on the tape, but I used other methods to
determine that - usually experimenting with dd and small block sizes
until I got to the point where it no longer errors.
One of my favorite pastimes was to read until the soft EOT (usually a
double EOF), and then do a "mt fsf". Depending on the tape drive, this
could advance the tape beyond the soft EOT where more data might be
saved. The idea being that a tape had been overwritten from the
beginning, but with less data overall.
So it would look like this: |data|EOF|data|EOF|data|EOT|short
data|EOF|data|EOF|data|EOT|blank|Hard-EOT
I used this method to rescue a TOPS-10 6.03A install monitor from a
backup set that was past the soft EOT on one of my own personal tapes.
I've rescued a lot of other data that way too.
For anyone reading old tapes, I implore you to attempt to read data past
the soft EOT ;)
On 11/19/2017 12:49 PM, Noel Chiappa wrote:
> > From: Will Senn
>
> > I think I understand- the bytes that we have on hand are not device
> > faithful representations, but rather are failthful representations of
> > what is presented to the OS. That is, back in the day, a tape would be
> > stored in various formats as would disks, but unix would show these
> > devices as streams of bytes, and those are the streams of bytes are what
> > have been preserved.
>
> Yes and no.
>
> To start with, one needs to differentiate three different levels; i) what's
> actually on the medium; ii) what the device controller presented to the CPU;
> and iii) what the OS (Unix in this case) presented to the users.
>
> With the exception of magtapes (which had some semantics available through
> Unix for larger records, and file marks, the details of which escape me - but
> try looking at the man page for 'dd' in V6 for a flavour of it), you're correct
> about what Unix presented to the users.
>
>
> As to what is preserved; for disks and DECtapes, I think you are broadly
> correct. For magtapes, it depends.
>
> E.g. SIMH apparently can consume files which _represent_ magtape contents (i,
> above), and which include 'in band' (i.e. part of the byte stream in the file)
> meta-data for things like file marks, etc. At least one of the people who
> reads old media for a living, when asked to read an old tape, gives you back
> one of these files with meta-data in it. Here:
>
> http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/tools/rdsmt.c
>
> is a program which reads one of those files and convert the contents to a file
> containing just the data bytes. (I had a tape with a 'dd' save of a
> file-system on it, and wanted just the file-system image, on which I deployed
> a tool I wrote to grok 4.2 filesystems.)
>
>
> Also, for disks, it should be remembered that i) and ii) were usually quite
> different, as what was actually on the disk included thing like preambles,
> headers, CRCs, etc, none of which the CPU usually could even see. (See here:
>
> http://gunkies.org/wiki/RX0x_floppy_drive#Low-level_format
>
> for an example. Each physical drive type would have its own specific low-level
> hardware format.) So what's preserved is just an image of what the CPU saw,
> which is, for disks and DECtapes, generally the same as what was presented to
> the user - i.e. a pile of bytes.
>
> Noel
>
next prev parent reply other threads:[~2017-11-19 18:35 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-19 17:49 Noel Chiappa
2017-11-19 18:35 ` Arthur Krewat [this message]
-- strict thread matches above, loose matches on Subject: below --
2017-11-20 19:42 Noel Chiappa
2017-11-20 17:00 Noel Chiappa
2017-11-20 16:01 Noel Chiappa
2017-11-20 17:37 ` Will Senn
2017-11-19 20:46 Steve Simon
2017-11-19 18:45 Noel Chiappa
2017-11-19 13:41 Noel Chiappa
2017-11-19 14:55 ` Clem cole
2017-11-19 21:00 ` William Corcoran
2017-11-19 21:19 ` Ron Natalie
2017-11-19 22:00 ` Dave Horsfall
2017-11-19 22:38 ` Lyndon Nerenberg
2017-11-19 22:40 ` Ronald Natalie
2017-11-19 23:41 ` Dave Horsfall
2017-11-20 1:02 ` Ronald Natalie
2017-11-20 1:18 ` Dave Horsfall
2017-11-20 18:12 ` Random832
2017-11-20 23:22 ` Dave Horsfall
2017-11-20 23:35 ` William Pechter
2017-11-21 0:01 ` Ron Natalie
2017-11-20 19:02 ` Paul Winalski
2017-11-19 14:55 ` Will Senn
2017-11-18 19:23 Noel Chiappa
2017-11-18 21:32 ` Will Senn
2017-11-18 21:49 ` Warren Toomey
2017-11-18 18:34 Noel Chiappa
2017-11-18 18:37 ` Ronald Natalie
2017-11-18 18:40 ` Ronald Natalie
2017-11-18 21:51 ` Dave Horsfall
2017-11-18 21:07 ` Will Senn
2017-11-18 22:53 ` Clem Cole
2017-11-19 1:47 ` Will Senn
2017-11-18 16:39 Will Senn
2017-11-18 18:57 ` Clem Cole
2017-11-18 20:03 ` Don Hopkins
2017-11-18 22:37 ` Dave Horsfall
2017-11-18 23:16 ` Don Hopkins
2017-11-18 23:35 ` Arthur Krewat
2017-11-19 0:35 ` Steve Nickolas
2017-11-19 0:42 ` Don Hopkins
2017-11-19 1:04 ` Clem cole
2017-11-19 16:20 ` Arthur Krewat
2017-11-20 2:33 ` Lawrence Stewart
2017-11-18 21:26 ` Will Senn
2017-11-18 22:39 ` Clem Cole
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=055c3e7f-6da9-497d-149a-16f230f55391@kilonet.net \
--to=krewat@kilonet.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).