Re: tar, but not gnu tar

Hi Everybody,

I had a bit of time to experiment with tar and star today
and I am no longer sure what the real issue is. Perhaps
some of you can clarify. Here's the test I ran:

There are many a ways to get the same thing done, but I
did it in a most intuitive way (to me). I had 3 windows
to the same directory. In one window, I ran a simple
shell program interactively and continuously:
while true
do
touch big.inputfile
done

And in the 2nd window, I ran a command:
tar cf ../moo.tar . > tar_errlog 2>&1

There are a bunch of files in this directory and below,
but one of them (big.inputfile) is 4.7gb. The above
tar command exited with exit status 0 and a line like:
tar: ./input.big: file changed as we read it
The tar I used is version 1.14.

Also, in the 3rd window, I ran a command:
star cf ../moo.star . > star_errlog 2>&1

Everything else remained the same. Here, start exited
with 0 as well, while it gave me this line in errlog:
star: 418759 blocks + 0 bytes (total of 4288092160 bytes = 4187590.00k).

The star version is 1.5a25.

Here's what started this very thread:

> Some backup tools that you might wish to use emit warnings or errors
> if the files they are trying to copy change while the copy proceeds.
> This situation is normal, and not an error, when taking a base backup
> of an active database; so you need to ensure that you can distinguish
> complaints of this sort from real errors. For example, some versions
> of rsync return a separate exit code for "vanished source files", and
> you can write a driver script to accept this exit code as a non-error
> case. Also, some versions of GNU tar consider it an error if a file is
> changed while tar is copying it. There does not seem to be any very
> convenient way to distinguish this error from other types of errors,
> other than manual inspection of tar's messages. GNU tar is therefore
> not the best tool for making base backups.

Is the issue to do with the exit code of the backup program? If that's
the case, both tar and star (at least with these very versions) are not
acceptable. Or is the issue to do with what the program spits out as
human readable message, which should be or shouldn't be ignored?

Another big problem I see is that neither program lists the exit codes
in the man pages. That's not good. Rsync man page has a section where
all exit code is listed, but I have no foreign drive on this host. I
am tempted to get a tiny machine just to do the backup.

I'd be interested your insights and thoughts.

Regards,

Tena

-----Original Message-----
From: Kenneth Marshall [mailto:ktm(at)rice(dot)edu]
Sent: Wed 8/22/2007 5:30 AM
To: Tena Sakai
Cc: Kevin Grittner; pgsql-admin(at)postgresql(dot)org
Subject: Re: [ADMIN] tar, but not gnu tar

Tena,

We have been very happy with star. It is a very nice pax,
cpio, gnutar,... replacement. You may want to give it a try.

Ken

On Tue, Aug 21, 2007 at 06:53:53PM -0700, Tena Sakai wrote:
> Hi Kevin,
>
> Yes, I have, but I am much more familiar with tar.
> I think I will go with the latest gnu tar (v 1.18)
> which is suggested by Bruce. I will play with it
> tomorrow and see how it goes.
>
> Thanks.
>
> Tena
>
> tsakai(at)gallo(dot)ucsf(dot)edu
>
>
> -----Original Message-----
> From: Kevin Grittner [mailto:Kevin(dot)Grittner(at)wicourts(dot)gov]
> Sent: Tue 8/21/2007 6:02 PM
> To: Tena Sakai; pgsql-admin(at)postgresql(dot)org
> Subject: Re: [ADMIN] tar, but not gnu tar
>
> >>> On Tue, Aug 21, 2007 at 7:28 PM, in message
> <FE44E0D7EAD2ED4BB2165071DB8E328C03062B59(at)egcrc-ex01(dot)egcrc(dot)org>, "Tena Sakai"
> <tsakai(at)gallo(dot)ucsf(dot)edu> wrote:
> >
> > On my linux machine, gnu tar is the tar. Does
> > anybody have a suggestion as to where I can go
> > to get a tar that is not gnu?
>
> Have you considered using cpio instead?
>
> http://www.gnu.org/software/cpio/
>
> -Kevin
>
>
>
>