multivol piped to tar

[Chris Torek]

In article <360 at prairie.UUCP> dan at prairie.UUCP (Daniel M. Frank) writes:
>   Does anyone know why tar should just stop silently?  The only
>thing I can think is that multivol doesn't provide its data in
>disk-sector-size blocks, since part of each multivol block is taken
>up with an eight-byte header.  That doesn't make much sense across
>a pipeline, unless tar is timing its reads, which doesn't make
>much sense either.  Any ideas?

Chances are that this is indeed the problem.  I cannot speak for
`The Standard', but for all us nonstandard folk running 4.2 or
4.3BSD, tar has the `B' option to re-block its input.

Tar has a section of code that looks about like this:

	n = read(tape, buffer, blocksize);
	if (n < blocksize)
		/* complain, or perhaps just exit */ ...

Because it is reading a tape drive, tar is rather fussy about the
number of bytes returned from read calls.  In particular, it should
always be the same, and it should be a multiple of 512 bytes.  But
wait, what is this?  Tar is *not* reading from a tape!  Ai, trouble.

When tar is reading from a pipe, read() returns a number that is
between one and the internal pipe buffer size (or blocksize,
whichever is less).  As it happens, if the writer of a pipe always
writes in multiples of buffer-size bytes, the reader (tar) will
always get buffer-size bytes back.  If the writer is slow enough,
and always writes $c$ bytes, where $c$ is less than buffer-size,
tar will always get $c$ bytes.  But it also sometimes happens that
the writer will not co-operate so nicely.

If you supply the `B' option, or in 4.3BSD, if you tell tar to read
from standard input, that section of code will be replaced with
one more like this:

	left = blocksize;
	p = buffer;
	do {
		n = read(tape, p, left);
		if (n <= 0)
			/* handle eof or error */ ...
		p += n;
		left -= n;
	} while (left);

For those of you suffering with `The Standard', if your tar does not
have a re-blocking option, there is always this trick:

	(commands) | cat | tar xbf 1 -

(assuming your `cat' will do the re-blocking).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	seismo!mimsy!chris	ARPA/CSNet:	chris at mimsy.umd.edu