Path: utzoo!attcan!uunet!cs.utexas.edu!usc!ucsd!ucbvax!mindcrf.UUCP!karish
From: karish@mindcrf.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: tar -r on a diskfile/tar arg too long
Summary: Use the source.
Keywords: tar -r on disk file
Message-ID: <9006091600.AA22128@mindcrf.mindcraft.com>
Date: 9 Jun 90 16:00:02 GMT
References: <1339@ziggy.EDU> <225@rossignol.Princeton.EDU> <1340@ziggy.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: Mindcraft, Inc.
Lines: 58

In article <1340@ziggy.EDU> ssi@ziggy.cmd.usf.edu.UUCP (Ssi) writes:
>In article <1339@ziggy.EDU> ssi@ziggy.EDU (Ssi) writes:
>$ Does anyone know any draw backs/problems with using the -r option of
>$ tar(1) on disk files, as in:
>$ 
>$ cat /dev/null > TARFILE
>$ tar -cvf TARFILE long_list       <<-- table of contents as first file
>$ for i in `cat long_list`
>$ do
>$ tar -rvf TARFILE $i             <<-- append each file to TARFILE
>$ done
>$ tar -cvf /dev/rmt0 TARFILE      <<-- put the whole thing to tape 
>$ rm TARFILE

Unless nested tar files are somehow advantageous, I'd use 'dd' to
put TARFILE to tape.  This lets you choose the biggest block size
your tape drive can handle, which often results in a substantial
increase in tape capacity.  The tradeoff is in portability; drives
vary in the block size they can handle.

>$ note:
>$ tar -cvf /dev/rmt0 `cat long_list` 
>$ Would give tar argument too long error.

If 'tar -r' turns out to be the best answer, use 'xargs' instead of
the shell loop.  It'll minimize the number of seeks and process
creations needed.

>Maybe I should mention that this is part of a bigger picture, to
>backup a network that requires more than one tape, and has to
>run on a `live' system.

In this context, the proposed scheme makes less sense than it did
before.  Where do you find disk space for the tremendous working file?
You can't back up the whole system unless half the server's disk
is kept free.

As previously noted, cpio works fine with an arbitrarily long
input list (on stdin, not on the command line).  If your system
doesn't have it, or you don't care for the user interface or
the error messages, try one of the public domain or freely-
distributable tar programs like pax, pdtar, or GNUtar.  I think
pax and GNUtar can read long input lists.  With the source,
it's not hard to make any of 'em do it.

The real trick is to handle multi-volume archives properly.  Some tape
drives can sense end of tape and report it in a timely fashion, and
others can't; ditto for the drivers that should listen for those
reports.  The usual remedy has been to tell the program how long your
tape is and what average data density you expect, and let the program
guess how much will fit on each volume.  You should adjust these
parameters (yes, lie to tar!) to take into account the block size
you're using and the characteristics of your tape drive: different
drives put different-length gaps between blocks.
-- 

	Chuck Karish		karish@mindcraft.com
	Mindcraft, Inc.		(415) 323-9000