Path: utzoo!mnetor!uunet!husc6!uwvax!oddjob!gargoyle!ddsw1!karl
From: karl@ddsw1.UUCP (Karl Denninger)
Newsgroups: comp.unix.xenix
Subject: Re: SCO 2.2.1 tar question
Message-ID: <1003@ddsw1.UUCP>
Date: 2 May 88 01:28:34 GMT
References: <8WQW5Ky00Vs8MSNUQN@andrew.cmu.edu> <10582@steinmetz.ge.com> <100@pigs.UUCP>
Reply-To: karl@ddsw1.UUCP (Karl Denninger)
Organization: Macro Computer Solutions, Inc., Mundelein, IL
Lines: 76
Summary: Huh?   I have *many* different floppy formats

In article <100@pigs.UUCP> haugj@pigs.UUCP (John F. Haugh II) writes:
>> In article <8WQW5Ky00Vs8MSNUQN@andrew.cmu.edu> jl42+@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.
>
>first off, last time i checked there was no 96 tpi 9 sector device.  the
>only 96 tpi device was 15 sectored.

My Xenix system (2.2.1, no wierd stuff) shows the following:

brw-rw----   1 asg      mail       2, 52 Mar 23 15:27 /dev/fd0
brw-rw-rw-   2 root     mail       2,  4 Apr 10 23:23 /dev/fd048
brw-rw-rw-   1 root     mail       2, 12 Jun 29  1987 /dev/fd048ds8
brw-rw-rw-   2 root     mail       2,  4 Apr 10 23:23 /dev/fd048ds9
brw-rw-rw-   1 root     mail       2,  8 Jun 29  1987 /dev/fd048ss8
brw-rw-rw-   1 root     mail       2,  0 Jun 29  1987 /dev/fd048ss9
brwx---rw-   1 root     root       2, 52 Apr 30 20:27 /dev/fd096ds15
brw-rw----   1 asg      mail       2, 36 Apr 10 23:12 /dev/fd096ds9

There are also raw devices to correspond with each of these.

>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.
>
>i suppose the correct response now would be `RTFM'.

Let's be a little more charitable, ok?

I take it you're trying to compress the data stream as it goes to disk.  To 
do this successfully you need a program that will block the data into
disk-sized chunks, and prompt for additional disks.  Given such a program
called 'stream', for example, you do this:

tar cf - /pathname | compress | stream >/dev/rfd096ds9

If you know that the data will fit on one disk you can do:

	tar cf - /pathname |compress >/dev/rfd096ds9

But if this returns an "out of space" error you're hosed -- it will not wait
for you to change disks.

If your archive doesn't fit on a single disk, and you don't have a 'streamer' 
you've got a real live problem.  I don't know of any good solutions to it 
either -- what you're trying will not work, as the second 'tar' is looking 
for *filenames* to fetch on it's standard input and you're sending it
compressed *data*.

Note that the 'raw' device is *necessary* as you must insure that no data
remains buffered in the cache before attempting to change disks lest some
of the data not be on the disk later when you go looking for it!  

(BTW: Those of you who are using floppies, and not using 'afio' (the cpio
replacement posted earlier on) should *seriously* consider it.  The best
feature is the ability to pick up in the middle of an archive, AND skip over
bad spots in the media.  If there is enough interest I can make it available
for anonymous uucp.)

-----
Karl Denninger                 |  Data: +1 312 566-8912
Macro Computer Solutions, Inc. | Voice: +1 312 566-8910
...ihnp4!ddsw1!karl            | "Quality solutions for work or play"