Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!agate!darkstar!cats.ucsc.edu!jik
From: jik@cats.ucsc.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.questions
Subject: Re: How to archive several files with tar?
Message-ID: <16978@darkstar.ucsc.edu>
Date: 12 Jun 91 21:22:00 GMT
References: <626E0BEE3F3F601CC4@lure.latrobe.edu.au> <ADRIANHO.91Jun9105223@barkley.berkeley.edu> <16873@darkstar.ucsc.edu> <2740@root44.co.uk>
Sender: usenet@darkstar.ucsc.edu
Organization: University of California, Santa Cruz
Lines: 41

In article <2740@root44.co.uk>, gwc@root.co.uk (Geoff Clare) writes:
|> In <16873@darkstar.ucsc.edu> jik@cats.ucsc.edu (Jonathan I. Kamens) writes:
|> >In article <ADRIANHO.91Jun9105223@barkley.berkeley.edu>, adrianho@barkley.berkeley.edu (Adrian J Ho) writes:
|> >|> In the worst case, it could be the _last_ file included, which means
|> >|> that your tar file could end up being _twice_ as large as it's
|> >|> supposed to be.
|> 
|> >  Actually, the worst case is that the tar file will continue to grow as tar
|> >writes into it, so that when tar opens that file to archive it, the file will
|> >grow as tar is archiving it, which means that there will be more to archive,
|> >etc., etc. until the disk fills up or the user exceeds his quota or the
|> >maximum file size or whatever.
|> 
|> Actually, Jonathan is wrong and Adrian was right.

Um, no.

|> Although many utilities will fill the disk if made to read their output
|> file, this is not true of tar (unless you have a broken tar).  In the tar
|> output format the size of each file is contained in a header which
|> precedes the file's contents.  Hence the amount of data which tar will
|> read from its own output file is limited to its size when tar starts
|> reading it.  If the output file is the last input file, it will
|> approximately double in size when tar reads it.
|> 
|> Any decent version of tar will warn you if an input file changes in size.

I have *used* a version of tar which does not do proper version checking, and
which therefore creates a tar archive that fills the disk.  I would not have
mentioned it if I hadn't used it.

Now, perhaps my recollection is wrong, and I didn't actually ever use such a
tar.  But unless you're willing to make the categorical claim that such a tar
does not exist (which you appear to be unwilling to do, since you said "unless
you have a broken tar" and later "Any decent version of tar"), saying that I
am "wrong" is unwarranted.

I was talking about the "worst case," i.e. a poor version of tar.

-- 
Jonathan Kamens					jik@CATS.UCSC.EDU