Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!amdcad!sun!pitstop!sundc!seismo!uunet!munnari!goanna!yabbie!rcodi
From: rcodi@yabbie.rmit.oz (Ian Donaldson)
Newsgroups: aus.wanted,comp.sys.apollo
Subject: Re: Wanted: Apollo RBAK info
Message-ID: <693@yabbie.rmit.oz>
Date: 11 Feb 88 02:12:38 GMT
References: <692@yabbie.rmit.oz>
Organization: RMIT Comm & Elec Eng, Melbourne, Australia.
Lines: 132

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