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 [EMAIL PROTECTED] -----Original Message----- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Wed 8/22/2007 10:18 PM To: Bruce Momjian Cc: Tena Sakai; Kenneth Marshall; Kevin Grittner; pgsql-admin@postgresql.org Subject: Re: [ADMIN] tar, but not gnu tar Bruce Momjian <[EMAIL PROTECTED]> 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
