finding out how a tape has been written.

[malvin drakley]

Hi there, can anyone point me in the direction of a utility on HP-UX that determines how a tape is written, i.e. tar,dd or cpio and what the block size is. I worked on ICL's DRS-NX for several years and we had a unix command called "whattape". I have discovered a routine for aix, but need a similar function on HP-UX.
I was given a tape yesterday that was allegedly a cpio backup from a customer who needed to restore some data, but I was unable to get any meaningful data from it
thanks in anticipation
malvin

[Paula J Frazer-Campbell]

Hi Malvin

Try Here:-

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=87318


Paula

[malvin drakley]

Hi Paula, thanks for the quick reply. I have looked through the thread you have supplied and tried several of the options, but as yet have beeen unable to determine a block size on the cpio tape,
will keep trying
malvin

[Cheryl Griffin]

Try:
# dd if=/dev/rmt/0mn of=/tmp/test bs=1K count=2
# file /tmp/test

The file command should return what format the tape is (cpio, tar, etc.).

[malvin drakley]

Thanks Cheryl, I have tried that but it still does not let me know what block size the cpio was written with. I tried my tape with and without the -c option and each way that I tried it, it said "perhaps you should try the -c option" or vice versa
malvin

[Cheryl Griffin]

The file command will only help you confirm that you're working with a cpio tape.

Can pax read the tape? Pax can read tar and cpio formats. If pax cant read the tape, it could be that the tape is bad:
# pax -r -f /dev/rmt/0m

[malvin drakley]

Thanks Cheryl, the customer as they say "has just left the building", we are getting a message to him to bring the tape back tomorrow morning, so will let you know the outcome then when I have tried the latest suggestion you have given me
cheers
malvin

[Bill Hassell]

Unlike mainframes where a tape recognition daemon (they aren't really called that but function that way) is used to ID a tape header, HP-UX doesn't have anything like that. Instead, you can use the guessing program called file. File is a magic program. OK, it uses a file call /etc/magic which is a series of codes to tell file how to match up something at the beginning of a file (or device file) with common formats. So the commands:

mt -t /dev/rmt/0m
dd if=/dev/rmt/0m of=/var/tmp/tapeid count=2
file /var/tmp/tapeid

should tell you about the tape, assuming that it is in a 'well-known' format like tar, cpio, etc. (note that /dev/rmt/0m is an example--use the correct device file for your system) It is IMPOSSIBLE to determine if the tape was created with dd since dd is a raw copy of . Also, tape formats from mainframes (ie, ANSI or IBM labeled tapes) are not recognized by file. However, you can see if it is a mainframe labeled tape by using xd as in:

mt -t /dev/rmt/0m
xd -xc /dev/rmt/0m | more

If you see something like VOL as the first 3 characters and subsequent header lines like HDR1, HDR2, etc then you have an ANSI labeled tape. If the characters are strange, it might be in EBCDIC mode so use something like this to translate:

mt -t /dev/rmt/0m
dd if=/dev/rmt/0m od= count=2 conv=ebcdic | xd -xc

If thisa looks like VOL HDR etc records are present, you have an IBM standard label. The bad news about ANSI or IBM standard laebls is that there is nothing in HP-UX that can read the data and make sense out of it. If the tape contains fixed length records, you can probably play with mt (for positioning the tape) and dd to do a raw copy and translate from EBCDIC if necessary. But if the format is variable length, you'll have to write a program to interpret the records, essentially the basics of a mainframe restore program.

[malvin drakley]

Hi Bill, thanks again for the info, as I said to Cheryl it will be tomorrow before I get another chance to check the tape,
so will let you know sometime tomorrow
cheers
malvin

[malvin drakley]

Hi to Cheryl and Bill, The customer arrived with the tape again yesterday. He says it was written on a SCO box(I've washed my mouth out!). I have tried the "pax" command and the response from that was "this doesn't look like a tar archive, skipping to next file" and then the # prompt.
I then tried your suggestions Bill and cannot see anything like you suggest, so I have "dd'd" the first 10 blocks in and am attaching them for your perusal. It all looks like plain text so I am not certain as to the kind of tape
cheers
malvin

[Mark Grant]

Looks like a tar file to me.

I could also be wrong here but if I remember my SCO (which I probably don't because it was a long time ago) the default block size was 512 when using tar. So try tar with a block size of 512.

[Mark Grant]

actually, if you count the number of chars from the "M" of "MEDIA_NO 1" to the character before the "R" in "RADAN" which I imagine is one block you get 512 so maybe my memory isn't failing after all.

[Mark Grant]

Sorry to keep chatting to myself here but I suddenly have a vague memory of a bs of 20 on SCO. This doesn't make sense but I think the old SCO "tar" was a bit odd (apart from the nice option of taking the rest of it's arguments from a file).

[malvin drakley]

Hi Mark thanks for that, what is the syntax for making it read in 512?
when I used tar -tvf previously it said "tape error"
cheers
malvin

[Mark Grant]

malvin,

Looking into tar a bit more, it would seem that what I said before doesn't mean too much. The default blocking factor for tar is 20 and tar always writes logical blocks of 512. It is mentioned that if you are having trouble, use a blocking factor of "1", it is slow but has most chance of success. In this case you would do

"tar tvbf 1 ", change the "t" to an "x" to actually extract.

However, you do definately have a "tar" file on that tape.

[H.Merijn Brand (procura]

tape size block can be found by reading ONE block with extreme size:

# dd if=/dev/rmt/0m of=xx ibs=1024000
# ls -l xx

that's the tape block size (unless it's written on AS4e00, which uses variable block sizes, and you have to write a script that reads those huge blocks from no-rewind device and catenates them to something sane)

# file xx

will give you the file type, but others already said so.

# dd if=xx ibs=512 | tar tvf -

If you do this over a network interface, double buffering might help

# remsh host dd if=/dev/rmt/0m ibs=102400 | dd | dd >xx

A last tip, use GNU tar. It's quite a bit more capable in recovering different tapes and block sizes, and supports command line options to pass any block size you want

GNU tar is also available on my ITRC site:
Singapore https://www.beepz.com/personal/merijn/
Rotterdam http://www.cmve.net/~merijn/
Seattle http://ww.hpux.ws/merijn/

Enjoy. Have FUN! H.Merijn

[malvin drakley]

Thanks again to both of you, I have tried your suggestions Mark and I get the response "directory checksum error"

Do I call you Mr Procura??
I have now tried your suggestions and for ls -l xx I get "11958272" and for file x I get "ascii text"
when I try the next command I get the same message as above,so will now have to try and use your GNU tar

I'm not giving up yet!!
malvin

[H.Merijn Brand (procura · Accepted solution]

What a _strange_ number. that is 11678k
Does that ring a bell?

Ahh, no, *I* missed one argument.

# dd if=/dev/rmt/0m of=yy ibs=1024000 count=1
# ls -l yy

Pfeew, much better.

Could you show us the output of

# od -x xx | head

You can call me Merijn

FWIW, you have just read the complete tape to the file xx, so you can now use that as device :)

Enjoy, Have FUN! H.Merijn

[malvin drakley]

Hi Merijn, here is the output you have requested,
malvin

[H.Merijn Brand (procura]

This is not a unix standard format. At least *I* don't know it, and tar won't help, not even GNU. Roughly translated:

--8<---
MEDIA_NO 1

RADAN 1.000000

23583 ring.att

#DAT_LEL:6
0........
-->8---

Is this converted from a real tape? Those had a ring in it that you can pull out to make it write protected.

Enjoy, Have FUN! H.Merijn

[malvin drakley]

I didn't think that you were senior enough to remember 2400' reel to reel tape drives!!.
I think that I have got to really press the customer to come up with the answer as to how the tape was originally created on the SCO box, but I think he is just a "tape changer" rather than a technical person

Thanks again,
may open this again in a few more days when I can extract this information from him
cheers
malvin

[Bill Hassell]

That tape is definitely not in a Unix backup format such as tar, cpio, dump, pax, etc. It looks very much like an unlabeled ASCII tape with fixed records, which is good since dd will probably work to extract the data but you must have a layou of the original data. And as far as the SCO system ask the provider EXACTLY what they typed on the console to create the tape. My guess is that they probably typed the name of a database program and did an export, in which case, the format is 100% proprietary to the database used.