Re: tar, but not gnu tar

Hi Tom,
Hi Bruce,

Thanks for your input. Fair enough. I redid it.
This time, in the first window, I ran this mini
shell program continuously:

while true
> do
> date >> big.input
> done

In the 2nd window:

tar cf ../moo.tar . > tar_errlog 2>&1

Tar returned the exit code 0. In the tar_errlog, it said:
tar: ./big.input: file changed as we read it

In the 3rd:

star cf ../moo.star . > star_errlog 2>&1

Star returned exit code of 254. 6 lines were in
star_errlog:
star: 'big.input': file changed size (increased).
star: 419190 blocks + 0 bytes (total of 4292505600 bytes = 4191900.00k).
star: The following problems occurred during archive processing:
star: Cannot: stat 0, open 0, read/write 0. Size changed 1.
star: Missing links 0, Name too long 0, File too big 0, Not dumped 0.
star: Processed all possible files, despite earlier errors.

That was so different from the previous test, I ran
star one more time, but this time I killed the process
in the first window. Ie., I ran the same star test while
nothing was changing. It ruturned exit code 0, and a line
in the star_errlog:
star: 419467 blocks + 0 bytes (total of 4295342080 bytes = 4194670.00k).

I am inclined to use star. At the bottom of the star man page,
the author Joerg Schilling gives out his email address (3 of
them!) and I will email him and ask if he can supply a list of
all exit codes.

Regards,

Tena Sakai
tsakai(at)gallo(dot)ucsf(dot)edu

-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Wed 8/22/2007 10:18 PM
To: Bruce Momjian
Cc: Tena Sakai; Kenneth Marshall; Kevin Grittner; pgsql-admin(at)postgresql(dot)org
Subject: Re: [ADMIN] tar, but not gnu tar

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Tena Sakai wrote:
>> 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:

> I don't think 'touch' is enough for tar to see the file as changed (you
> are only updating metadata). (tar did complain but the file contents
> didn't so it is hard to say if that is a good test.) You should change
> the file contents during the backup.

In fact, I'll bet that you have to change the file *length* during the
backup to trigger gnu tar's complaint. If it were rigorously checking
for file content change, it'd have to read the whole of every file
twice, which hardly seems like overhead that anyone would accept. But a
check for length change would just mean one extra stat() call per file,
which is a whole lot more plausible.

regards, tom lane