My original question had to do with reading source code files from an 8mm tape
for which I had no information regarding how it was written (I have appended the
full original problem description).
I recieved many good suggestions. Here is the summary, with the solution that
worked first:
The winners were the suggestions to use tcopy to determine if the tape is
readable and what the block size is. This is a standard tool, /usr/ucb/tcopy,
and worked great! I found I had a block size of 64512. With that information, I
then tried restore (not) and then tar. The tape turned out to be a tar image
written with a block size of 64512. My one followup question... is there any
particular reason this size was chosen? This is one of the strangest block
sizes I have run across over the years (granted, I do try to avoid tapes when
possible).
Some asked whether the tape was written as a 2.3 GB or 5 GB tape. If my drive(s)
don't support the density written, clearly I wouldn't be able to read the tape.
Good try, but I am using autoselecting drives supporting both densities (I
didn't know this until these replies came in). More exotic densities were
mentioned, such as 10 GB and 20 GB, but this was not my problem and are only
starting to really hit the market. It was also suggested that the tape might be
compressed or encrypted. It was not, though these are good suggestions.
Others suggested the tape may have been written on a non-Sun machine and as a
consequence not readable. I can not check this, but I CAN now read the tape, so
this may not be a real limitation. In fact, I can read a tar file I wrote on a
DECstation 5000 running ULTRIX on my SunOS machine with no problems.
Another group of responses suggested ways of using dd to figure out the tape's
blocking and to look at the magic number/cookies to determine the tool to use to
read the tape. This would probably have worked if I had tried it before tcopy,
but tcopy is far simpler than the dd techniques. od was also suggested as a way
to peek at the first few bytes of the tape.
There were suggestions that I use different device names to try different
densities.
I was sent a tape cracking tool's source code. This looks like something quite
worthwhile as it would help to find the tool with which to read the tape in
addition to the block size.
Someone recommended that I first pull everything directly off the tape and then
deal with cracking its content. They suggested using tputil, tprobe, and
offered an alternative program totaltape. This also seems worthwhile.
Finally, someone asked that I make sure I use cr-s/eol-s in my email. I use Sun's mailtool v3 and had thought it was autowrapping for me. Is there a way to get mailtool to automatically insert cr-s/eol-s when it wraps lines? I probably should ask if there is a mailing list that is more appropriate for mailtool questions as I have a number of them. Unfortunately, I can not use news (I have no local news server) where I am sure I could find a fast and more appropriate channel than this list... anyway....
Thank you everyone for your help. I would not have solved my tape problem without you!
-Marc
>> I have an 8mm tape with some source code files on it that I can't read. The
>> tape was sent to me with no indication of how it was written, and successive
>> attempts at contacting the writer to get this information have thus far
>> failed.
>>
>> It is getting critical that I read this tape so I have to try guessing. So
>> far I have tried:
>>
>> 1. tar
>> 2. bar
>> 3. restore
>> 4. cpio
>> 5. dd
>>
>> All with no success. I have only attempted to use default block size as I
>> have no idea how to guess at a non-default block size.
>>
>> Can anyone help me crack this tape?
>>
>> Have I missed a possible write/read tool? Are there "standard" non-default
>> block sizes I should try? Are there any tools available to analyze the tape
>> and suggest the tool and arguments that might be the correct way to read it?
>> (Back in the old days, when I was running on a CDC 6400, we had a support
>> person who spent most of their time cracking tapes. They also
>> created/obtained a program that did a pretty good job of analyzing a tape and
>> suggesting the most likely way to read it. I thought those days were gone,
>> but I guess not... ;-)
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:13 CDT