1 Mar
2005
1 Mar
'05
3:12 p.m.
Having received some of these in the mail, what's the best way of
imaging them onto modern media?
I hooked up a 150MB SCSI QIC drive to my Linux PC, and it seems to be
able to pull data off them happily (even though they're only 60MB).
However the tapes contain multiple archives which I'm not too used to
handling, plus the archives aren't in any format known to Linux (so I
guess dd is the tool for the job there)
So, is it just as simple as making sure the tape's rewound, then keeping
on issuing: dd if=/dev/nrst0 of=archive01 (with a different output
filename each time) ? As nrst0 is a non-rewinding device, I assume the
tape will be left at the start of the next archive on the tape after
each dd command?
Or is it more subtle than that and the archives aren't necessarily back-
to-back? Do I need to be issuing some sort of mt command inbetween dd
commands to make sure the tape's positioned at the start of the next
archive each time?
cheers
Jules
1 Mar
1 Mar
3:39 p.m.
Jules Richardson wrote:
Having received some of these in the mail, what's
the best way of
imaging them onto modern media?
I hooked up a 150MB SCSI QIC drive to my Linux PC, and it seems to be
able to pull data off them happily (even though they're only 60MB).
However the tapes contain multiple archives which I'm not too used to
handling, plus the archives aren't in any format known to Linux (so I
guess dd is the tool for the job there)
So, is it just as simple as making sure the tape's rewound, then keeping
on issuing: dd if=/dev/nrst0 of=archive01 (with a different output
filename each time) ? As nrst0 is a non-rewinding device, I assume the
tape will be left at the start of the next archive on the tape after
each dd command?
Or is it more subtle than that and the archives aren't necessarily back-
to-back? Do I need to be issuing some sort of mt command inbetween dd
commands to make sure the tape's positioned at the start of the next
archive each time?
Look for "tapetools" on the web. It copies the tape into a container
file, preserving all blocksizes, so you can even duplicate it to another
tape (9track,8mm,4mm,dlt,...).
Includes also a tapedump utility, so you can have a look what's inside
3:52 p.m.
Jules Richardson wrote:
Look for "tapetools" on the web. It copies
the tape into a container
file, preserving all blocksizes, so you can even duplicate it to another
tape (9track,8mm,4mm,dlt,...).
Includes also a tapedump utility, so you can have a look what's inside
I'm not familiar with "tapetools", and Google only turned up references
to an HP proprietary program. Were you perhaps thinking of "tapeutils"?
http://www.brouhaha.com/~eric/software/tapeutils/
4:12 p.m.
Eric Smith wrote:
Jules Richardson wrote:
You're as usual right, my finger were much faster than the brain ;-)
The tapeutils I was recommending ...
cheers
Look for "tapetools" on the web. It
copies the tape into a container
file, preserving all blocksizes, so you can even duplicate it to another
tape (9track,8mm,4mm,dlt,...).
Includes also a tapedump utility, so you can have a look what's inside
I'm not familiar with "tapetools", and Google only turned up references
to an HP proprietary program. Were you perhaps thinking of "tapeutils"?
http://www.brouhaha.com/~eric/software/tapeutils/
2 Mar
2 Mar
9:17 a.m.
On Tue, 2005-03-01 at 17:12 -0700, emanuel stiebler wrote:
Will take a look at that - thanks.
Next question - anyone think of a good reason why a lot of old tapes I
have containing tar archives seem to hit read errors at around 7.8MB
into the tape?
This is reading a pile of *unknown* DC600 tapes in a 150MB drive. I
can't think of any reason why a lot of the tapes hit problems at almost
exactly the same point; I mean the head and motor assembly must be fine
to get that far. But equally it seems odd.
Maybe tar has a "don't break at 8MB-ish" parameter or something ;)
Or maybe the 150MB QIC drives aren't completely backwards-compatible
with the 60MB ones....
(these particular tapes are old, I don't know how many times they've
been used, what system wrote them even - but chunks of errors in the
same place seems like a strange coincidence!)
thoughts? Tried cleaning the drive already before anyone mentions it :)
cheers
Jules
12:02 p.m.
Jules Richardson wrote:
On Tue, 2005-03-01 at 17:12 -0700, emanuel stiebler
wrote:
Will take a look at that - thanks.
Next question - anyone think of a good reason why a lot of old tapes I
have containing tar archives seem to hit read errors at around 7.8MB
into the tape?
This is reading a pile of *unknown* DC600 tapes in a 150MB drive. I
can't think of any reason why a lot of the tapes hit problems at almost
exactly the same point; I mean the head and motor assembly must be fine
to get that far. But equally it seems odd.
thoughts? Tried cleaning the drive already before anyone mentions it :)
Did you retension and erase the tapes? *ducks*
I don't know all that much about QIC in general, but I had the same
problem with *two* Tandberg TDC3600 drives this week. I found my TDC
4220 and had no problems at all with the same cartridges.
I sort of wonder if it's SCSI-I vs SCSI-II - these were hanging off a
U2W Symbios adapter. For two drives to hiccup the same way in almost
the same place, on several different tapes (two of which proved good on
the TDC 4220), and with you seeing the same behavior, I think that's a
protocol glitch.
Doc
1:18 a.m.
On Tue, 01 Mar 2005 23:12:58 +0000
Jules Richardson <julesrichardsonuk at yahoo.co.uk> wrote:
Having received some of these in the mail, what's
the best way of
imaging them onto modern media?
cptape and maketape from your favorite TUHS mirror,
e.g.
http://mirror.cc.vt.edu/pub/projects/Ancient_Unix/PDP-11/Tools/Tapes/
http://mirror.cc.vt.edu/pub/projects/Ancient_Unix/PDP-11/Distributions/ucb/…
--
tsch??,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
7235
days inactive
7236
days old
6 comments
5 participants
participants (5)
-
doc＠mdrconsult.com -
emu＠ecubics.com -
eric＠brouhaha.com -
jkunz＠unixag-kl.fh-kl.de -
julesrichardsonuk＠yahoo.co.uk