Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!pacbell.com!tandem!zorch!vsi1!frame!bugeater.UUCP!tvb
From: tvb@bugeater.UUCP (Terry V. Bush)
Newsgroups: comp.sys.apollo
Subject: Re: Tar
Message-ID: <17592@frame.UUCP>
Date: 4 Apr 91 03:27:43 GMT
References: <50bc51ca.1bc5b@pisa.citi.umich.edu> <9104020018.AA18211@cml.unl.edu>
Sender: news@frame.UUCP
Organization: Frame Technology, 1010 Rincon Cir., San Jose, CA 95131
Lines: 101


mt -f /dev/rct12 rew
tar cvf /dev/rct12 file1 file2 file3 ...
tar cvf /dev/rct12 file4 file5 file6 ...
tar cvf /dev/rct12 file7 file8 file9 ...

To extract:

mt -f /dev/rct12 rew
tar xvf /dev/rct12
tar xvf /dev/rct12
tar xvf /dev/rct12

You don't need to do any of this "dd" stuff!

Note: Unlike many other platforms, the Apollo does not need a "fsf 1" step
between the "tar xvf"'s.  Why they didn't use /dev/nrct8 is beyond me!

You can use the /etc/edmtdesc command to look at the two files.
Here is what I say on them:

% edmtdesc /dev/rct12 -l
Volume information:
    dev     (device type)                   ct
    u       (tape unit #)                   0
    lab     (labeled)                       no
    reo     (reopen previously used volume) yes
    clv     (close volume on file-close)    yes
    spos    (save position on volume-close) yes

File information:
    f       (file sequence #)               current
    rf      (record format)                 F  (fixed length)
    bl      (block length)                  512
    rl      (record length)                 512
    ascnl   (ascii newline handling)        no


% edmtdesc /dev/rct8 -l
Volume information:
    dev     (device type)                   ct
    u       (tape unit #)                   0
    lab     (labeled)                       no
    reo     (reopen previously used volume) yes
    clv     (close volume on file-close)    yes
    spos    (save position on volume-close) no

File information:
    f       (file sequence #)               current
    rf      (record format)                 F  (fixed length)
    bl      (block length)                  512
    rl      (record length)                 512
    ascnl   (ascii newline handling)        no


In article <50bc51ca.1bc5b@pisa.citi.umich.edu>, rees@pisa.citi.umich.edu (Jim Rees) writes:
> Path: frame!vsi1!ames!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!caen!umich!terminator!pisa.citi.umich.edu!rees
> From: rees@pisa.citi.umich.edu (Jim Rees)
> Newsgroups: comp.sys.apollo
> Subject: Re: Tar
> Message-ID: <50bc51ca.1bc5b@pisa.citi.umich.edu>
> Date: 2 Apr 91 17:22:42 GMT
> References: <9104020018.AA18211@cml.unl.edu>
> Sender: usenet@terminator.cc.umich.edu (usenet news)
> Reply-To: rees@citi.umich.edu (Jim Rees)
> Organization: University of Michigan IFS Project
> Lines: 27
> 
> In article <9104020018.AA18211@cml.unl.edu>, gah@cml.unl.edu (Glen A. Hansen) writes:
> 
>   While on the subject of "tar", is it possible to "tar" more than one archive to
>   a cartridge tape?
> 
> Not only is tar badly broken, but tape io is also broken (and always has
> been).  You can make this work but it's a pain.  You have to rewind and
> re-read each archive before writing the next.  The sequence is something
> like this:
> 
>   mt -f /dev/rct8 rew
>   tar cfv /dev/rct12 file1 file2 file3 ...
> 
>   mt -f /dev/rct8 rew
>   dd if=/dev/rct12 of=/dev/null bs=1k
>   tar cfv /dev/rct12 file4 file5 file6 ...
> 
>   mt -f /dev/rct8 rew
>   dd if=/dev/rct12 of=/dev/null bs=1k
>   dd if=/dev/rct12 of=/dev/null bs=1k
>   tar cfv /dev/rct12 file7 file8 file9 ...
> 
>   ...
> 
> This takes forever.  In fact, it's intractable, since the time required is
> exponential with the number of archives.  That means it doesn't matter how
> fast the tape drive is, it still takes too long.



	Peace,
	Terry V. Bush
	The Veritable Bugeater		tvb@frame.com		N6IFX