rcodi@yabbie.rmit.oz (Ian Donaldson) (02/10/88)
Does anybody know whether there is a difference in the actual -data-
recorded on an Apollo RBAK format 1/4" Cartridge versus the same data
recorded on an Apollo RBAK format 9-track 1/2" magtape?
(yeh, I know the block sizes are fixed at 512 bytes on a cartridge)
Why do I ask this? Well, its a long story...
We received this Cartridge containing about 18Mb of data, but our
DN660 (running SR9.2.3) has only a 1/2" 1600-bpi magtape drive.
However, we have a Sun-3 with a cartridge drive, so I thought that I might
as well read the tape there, then sendfile it up to the Apollo.
(it was QIC-24 format as far as the Sun thought, and "cat -v" verified
that it was not total garbage).
Upon the data arriving on the Apollo (all 18Mb of it in 18 or so files, one
file for each logical file on the tape), I thought that I'd just use
RBAK to decode it. No go! RBAK won't read from -anything- other than
a -real- tape. RWMT (the Apollo ANSI tape reader/writer) won't either.
Hmm, I thought. Why not write the stuff back to a 1/2" tape now that
it is on a machine that has one, and then use RBAK or RWMT to read it
back and unpack it?
The only problem with doing something like this is that RBAK and RWMT
expect the block sizes on tape to be EXACTLY right or they just
pewk at the sight of it.
Not knowing what the block sizes should be, I grabbed another RBAK magtape off
the shelf and discovered (by reading it on a VAX with dd) that the block sizes
were 80 bytes for the HDR1 and EOF1 blocks, and 8192 for the data in
the middle. 3 physical tape files per logical file. HDR1, data, EOF1.
I managed to generate a perfect copy of this RBAK magtape on the DN660 without
using WBAK (I used dd with the above block sizes), and upon reading
it back, RBAK liked it too. Great!
However, upon doing the same thing with the data from the Cartridge tape
RBAK -still- pewks at it!
Looking at the first header block from the real RBAK tape I wrote and the
data from the cartridge, there is only one startling difference -- there
is a lot more junk after the header in the Cartrige version. Also, the
cartridge version's header file was 2560 bytes long, but the magtape one
was only 400 bytes.
Hmmm again. Maybe this is not RBAK format? Well, I put the original
Cartridge in another department's DN3000 (running SR9.5) and it
reads perfectly with both RBAK -and- RWMT!
I can't find any Apollo doco about RBAK format anywhere, but I'm told
it is close to ANSI compatable, except that the acl formats, special file
info, directory info etc are not. An ANSI reader would skip all this
stuff since it is just part of the file data.
(incidently, I have another ANSI reader (ansii) grabbed from the net some
time back, which also pewks at it)
Any clues on how to convert RBAK cartridge data to magtape?
... or to unpack RBAK cartridge data once it is -off- the cartridge?
... or is it a difference between SR9.2 and SR9.5?
(I have no idea which version of Aegis the tape was written under)
... short of the obvious:
- pay somebody some enormous sum that has both drives to do it
- use two machines networked together to do it
(can you run the Ring via telecom? :-) Just joking.
Since we are likely to do a lot of this sort of thing in the future,
we would prefer a better method.
Ian Drcodi@yabbie.rmit.oz (Ian Donaldson) (02/11/88)
In article <692@yabbie.rmit.oz>, I wrote: > Looking at the first header block from the real RBAK tape I wrote and the > data from the cartridge, there is only one startling difference -- there > is a lot more junk after the header in the Cartrige version. Also, the > cartridge version's header file was 2560 bytes long, but the magtape one > was only 400 bytes. Well, I discovered what this was due to. When WBAK writes to a cartridge, it writes the HDR and EOF physical files as 80-character blocks, but they get padded to 512 bytes by something (the controller probably; maybe WBAK) with garbage. A quick program can be used to strip this garbage out: (error processing omitted for clarity) "xdd.c": --------------- |main(argc, argv) |char *argv[]; |{ | char *buf; | register int cc, input, output, ibs, obs, r; | | input = open(argv[1], 0); | output = creat(argv[2], 0666); | ibs = atoi(argv[3]); | obs = atoi(argv[4]); | | buf = malloc(ibs); | r = 0; | while((cc = read(input, buf, ibs)) > 0) { | if(cc > obs) | cc = obs; | if(write(output, buf, cc) != cc) | perror("write"); | r++; | } | | printf("%d blocks\n", r); | (void) close(output); |} --------------- Well, using this program on the cartridge data makes it ANSI compatable, (ie: RWMT likes it) but RBAK still chokes on the data blocks. I suspect this is because RBAK "knows" its is reading from a magtape and expects the data blocks to be 8192 bytes long (c.f. 512 for a cartridge). The following script output demonstrates: (f1 is a HDR file, f2 is a data file and f3 is a EOF file) --------------- |Script started on Thu Feb 11 12:26:36 1988 |% xdd f1 /dev/rmt12 512 80 |5 blocks |% xdd f2 /dev/rmt12 512 512 |19 blocks |% xdd f3 /dev/rmt12 512 80 |2 blocks |% rwmt -dev mt -index | |Volume label: | Volume ID: " " Owner ID: " " Access: " " | |File/Section File ID Cr Date Acc RF RL BL | 1 1 87/11/17 F 512 512 | |End of file set. |% rbak -dev mt -index -all -f 1 | |Label: | Volume ID: | Owner ID: (no owner specified) | File number: 1 | File section: 1 | File ID: (no id specified) | File written: 1987/11/17 11:19:53 ASET | |Starting index: | | |** Block length incorrect on data block 256 | Should be 536870916; is 512. Skipping this block. | |** Block length incorrect on data block 512 | Should be 536870916; is 512. Skipping this block. | -------- ...blah blah blah for a while -------- | |** Block length incorrect on data block 4864 | Should be 536870916; is 512. Skipping this block. | |Index complete. |% ^D |script done on Thu Feb 11 12:29:50 1988 --------------- What the 536870916 means I don't know. I suspect it is a bug. On observing the data file format using od, it appears that there are headers on every block. Since it came from a cartridge, this means every 512 byte block contains a header which has the pathname in it along with other binary stuff. If it came from a WBAK'd magtape, this header is only every 8192 bytes. [One wonders how efficient the cartridge is storing user data when the header is in -every- block! if the pathnames reach 100 chars long, then only 400 odd bytes per block are for user data it would seem! Obviously the headers are replicated to help ease read-error recovery.] Now, If I knew what the data part of RBAK format was, I could (reluctantly) write a converter to shift the headers, or just plain unpack the data! Another question: why is it not possible to do this: dd <file >/dev/rmt12 but this -is- possible: dd if=file of=/dev/rmt12 under bsd4.2? The former writes zero-length blocks onto the tape (ie: no data, just EOF marks). If it was reading from tape then it reads no data. "dd" is not broken, since it does the same with any other program (eg: my xdd above, until I rewrote it to open/creat instead of using fd 0/1) Ian D