SCO 2.2.1 tar question

[Len Reed]

in article <100 at pigs.UUCP>, haugj at pigs.UUCP (John F. Haugh II) says:
>
>> In article <8WQW5Ky00Vs8MSNUQN at andrew.cmu.edu> jl42+ at andrew.cmu.edu (Jay Mathew Libove) writes:
>> | Hi. I'm running SCO Xenix SysV/286 v2.2.1 on an IBM PC/AT clone and
>> | I am having a bit of a problem with "tar".
>> | I want to tar off a filesystem as:
>> |
>> | % tar cf - /pathname | compress | tar cfk /dev/rfd096ds9 720 -
>> |
>> | but when I do this I get:
>> |
>> | tar: blocksize must be a multiple of 2.
>
> this must be an april's fools day joke of some kind.  the person (jay libove)
> who posted the original article has made too many mistakes for this to be
> simple stupidity.

You must be an expert on simple stupidity.  I suggest that if you must be
insulting you shouldn't make so many errors in your comments.  You have supplied
incorrect information, probably misinterpreted the intention of the
original poster, failed to provide a solution, and failed to explain the
real source of the error message.

>
> first off, last time i checked there was no 96 tpi 9 sector device.  the
> only 96 tpi device was 15 sectored.

On your system, perhaps.  On the distribution system, perhaps.  The manuals
describe how to make a device that is any combination of {ss,ds},
{8,9,15} sectors per track, {48,96} tracks per inch.  Floppy device zero
with double sided 96 TPI, 9 SPT is minor device 36.  This format is useful
for getting the maximum amount of data (720K, the amount Jay specified in
his tar command) on a non high-density diskette.  (In a strictly literal
sense, /dev/rfd096ds9 is not necessarily device (2,36)--it is whatever the
filesystem says it is.  I'm assuming that Jay simply extended the existing
naming conventions or that you're wrong about what comes with the system.
I have a /dev/rfd096ds9, but I may have made it myself.  Refer to the
doecumentation on mknod(1), John, for how to add character-special devices.)

The ability to read and write almost any diskette is a very usful feature of
Xenix.  I often have to shuffle files to/from an NCR Tower, which uses
96 tpi, ds, 8 spt == 640K.  I even have /dev/rfd096ds8 linked to /dev/rtower,
further demonstrating my parenthetical remark above.
>
> secondly, you have two tar's with the 'c' option in the pipe line.  'c'
> stands for 'create archive', so the input of the second tar is coming from
> the files requested to be archived.  the /dev/rfd096ds9 [sic] device is
> going to be the output device, not standard output as requested with the
> '-' option.

True, but I think he wants '-' to be the input device.  (See below.)
>
> thirdly, assuming jay meant to use 'x' on the second tar, which is the
> only way for two tars in a pipe to work, the input would have been coming
> from compress, which is not in tar format.  you are lucky you only received
> a blocksize message.

It appears to be true that for two tars to work in a pipeline, the first must
be output to stdout and the second input from stdin.

I doubt that Jay wanted to extract in the second tar.  My guess is that
the intention was:
    First tar packs up the files into a tar archive and writes the
        archive to the pipe.
    Compress squeezes the tar archive and passes it along.
    Second tar reads the compressed archive and writes a tar archive
        containing a single file that is the compressed tar archive.

Tar (on Xenix) can read the stdin OR write the stdout, but it doesn't appear
to be able to do both at once.  (Surely the '-' in the second tar command
meant read the stdin.)  The problem is that tar won't accept
    tar cff - output_device
which seems to be what is wanted.

If the output of compress will be less than 720K, you can say

    tar cf - /pathname | compress | dd obs=20k of=/dev/rfd096ds9

If you REALLY need compress and > 720K, you may have to a little programming.
Tar won't read from a fifo, so this won't help.  (John probably didn't
consider this option since his system can't have fifos--they're built by
mknod.)  I know of no Xenix commands other that backup/dump and tar that handle
multiple diskette volumes.  I you can afford the hard disk space:
    tar cf - /pathname | compress >result
    tar cfkb /dev/rfd096ds9 720 20 result

where "result" is a normal file.  Note the addition of "b" and 20: these
specify the blocking factor of 20.  The default blocking factor is 1, which
apparently is unacceptable here.  Omitting the blocking factor yields
    "tar: blocksize must be a multiple of 2."
(Look familiar?)  It's better, though, to edit /etc/default/tar to include
a line describing the device, and then use its number in the command.
E.g., add the line
    archive4=/dev/rfd096ds9     20  720 n
and the use command
    tar c4 result
instead of
    tar cfkb /dev/rfd096ds9 720 20 result

Better compression be might be achieved by copying the entire heriarchy
(using cpio or tar), compressing the individual files, and then tarring the
shadow heirarchy.  Even if the compress step were done as part of the
heariarchy copy, using a script with a loop in it, you need hard disk space
for the whole compressed heirarchy.  (This also has the advantage that the
files on the diskette will be listable using "tar t" or "cpio -t".)

If you need multiple volumes and don't have the hard disk space for a copy,
you could create a simple filter that copies from stdin to stdout, stopping
every 720K (or better, an arbitrary amount) to ask for confirmation to
continue from /dev/tty.  Such a filter could be placed in a pipeline
between packaging (cpio or tar plus compress) and output (probably dd).
    find /pathname -print | cpio -oc | compress | new_filter 720k | dd obs=20k of=/dev/rfd096ds9

You'll also need a way of reading the floppies.  Perhaps appending each floppy
to a fifo while reading the fifo with uncompress.  (Use cpio instead of
tar to build the archive.)

I don't recommend you do it this way, though.  Having a single compressed
file strewn over several diskettes, requiring diskette concatination and
uncompress to even list the archive contents is awkward at best.
There must be better ways to get floppies with compressed archives.
I haven't used it, but perhaps "zoo" is what you want.