Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!uwvax!astroatc!prairie!dan
From: dan@prairie.UUCP (Daniel M. Frank)
Newsgroups: comp.unix.wizards
Subject: multivol piped to tar
Message-ID: <360@prairie.UUCP>
Date: Wed, 19-Nov-86 22:07:22 EST
Article-I.D.: prairie.360
Posted: Wed Nov 19 22:07:22 1986
Date-Received: Thu, 20-Nov-86 02:32:17 EST
Reply-To: dan@prairie.UUCP (Daniel M. Frank)
Distribution: world
Organization: Prairie Computing, Madison, Wisconsin
Lines: 35


   I have a very strange problem.  I am working with the multivol
program posted to net.sources (or was it mod.sources?).  I piped
tar into it, which seemed to work fine, but when I tried to pipe
its output into tar (i.e. from the diskette), tar would get through
a couple files and then stop with no error messages.

   Upon some investigation, I found that there is a problem with
the way multivol stores block sizes.  As it comes, they are
stored right-justified within the 6-character field, which leads
to problems when the data block following starts with numeric
characters (sscanf counts field sizes starting at the first
non-blank character).  Anyway, a simple fix to the write block
routines fixed that, and everything worked fine, right?

   Wrong.  I can direct the output of the program to a file, 
and feed that file into tar, and it works.  I can cat the file,
and pipe cat's output into tar's standard input, and it works (so
the problem doesn't seem to be seeks).  I cannot pipe the output
of the program into tar, and I cannot pipe the output of the program
into cat, and pipe cat's output into tar (i.e. a three stage pipeline).
I should mention that this problem occurs two files into the first
diskette, so it is not related to changing diskettes.

   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?

-- 
    Dan Frank
    uucp: ... uwvax!prairie!dan
    arpa: dan%caseus@spool.wisc.edu