Hi, I had a look in the archive to see if this had been covered already
but didn't find anything.
I just installed a new Debian server, the version of tar is 1.16 where
before it has been 1.14. My backup script is now failing where
previously it had functioned fine. It appears that tar is returning 1
when a file changes when being read (I have verified this by tarring the
output of tar). I found the below email which indicates that it should
not be a problems (see at bottom of post). But when I run the example,
it too returns 1. Is this a functional change for tar? Is there a way to
compensate for it? We use it on servers where files are changing constantly.
I have to say that I am impressed with the progress in tar (the improved
--exlude is much better) but am a little concerned at how
backwards-compatibility is being maintained.
Thanks
Rich
DNS2Svr:~# COUNT=100000
DNS2Svr:~# dd if=/dev/zero of=file count=$COUNT
100000+0 records in
100000+0 records out
51200000 bytes (51 MB) copied, 1.30391 seconds, 39.3 MB/s
DNS2Svr:~# dd if=/dev/zero of=file count=$COUNT seek=$COUNT &
[1] 2467
DNS2Svr:~# tar cf archive file
tar: file: file changed as we read it
DNS2Svr:~# echo $?100000+0 records in
100000+0 records out
51200000 bytes (51 MB) copied, 2.89545 seconds, 17.7 MB/s
1
Re: [Bug-tar] Separate return code when file changes while being read
Sergey Poznyakoff
Sat, 14 Oct 2006 04:14:14 -0700
Steve Bergman <[EMAIL PROTECTED]> wrote:
> If a file changes while tar is reading it, tar returns the same code as
> when there is a major problem like a tape write error.
>
> This makes it unusable for automated nightly backups. It is perfectly
> reasonable to want to include, for example, log files in the backup,
> which might be appended to while being read.
If the file is appended, tar exits with zero exit code. Try this test:
COUNT=100000
dd if=/dev/zero of=file count=$COUNT
dd if=/dev/zero of=file count=$COUNT seek=$COUNT &
tar cf archive file
echo $?
It gives:
tar: file: file changed as we read it
0
However, if the file is trucated, tar exits with status 2, indeed.
> Certainly, it is reasonable to return a nonzero code in the case that a
> file changes while being read, but it should not be the *same* nonzero
> code as for more serious problems.
Yes, I agree with that.
Regards,
Sergey
