Gnu Tar 1.12 Incremental Bug Report

From: Greg Ercolano <erco@sre.sony.com>
To: tar-bugs@gnu.ai.mit.edu
Subject: GNU TAR 1.12: incremental bug report
Date: Fri, 09 Oct 1998 14:23:00 -0700


Dear maintainer for GNU tar:

I think I have narrowed down a bug in GNU tar 1.12 with incremental
backups. It seems renamed files are not [being] restored correctly,
somehow relating to file timestamps.

History:
    I posted a message indicating I was having trouble with gnu tar
    incrementals on SGIs to comp.sys.sgi.admin. This begain a private
    email thread between me, Kay.Diederichs@uni-konstanz.de, and
    spd@daphne.cps.unizar.es which led to the eventual conclusion
    that something was wrong.

Results:
    We've all established we are getting the same undesireable
    results on both SGI and LINUX platforms. A script is enclosed
    that seems to 'can' the problem.

The Script:
    The following script creates some dirs and files, does a full
    backup, renames/moves files around, does an incremental backup,
    blows away the source directories, and tries to restore the
    full & incrementals to restore the original state of the file
    system.

    At the top, there is a configurable variable to enable the peppering
    of sleep commands between each operation.

The Problem:
    Uncomment 'SLEEP="sleep 2"' at the top, and the script FAILS.

    This is determined by the lack of restoration of one of the mv(1)ed
    files between the full and incremental backup.

    When both full and incremental are restored, the 'B' file does NOT
    restore.

    However, when no sleep is done, it appears to work ok, chance
    permitting that the clock does not change during script execution.
    One would actually expect the OPPOSITE to be true, where sleep
    commands would make it WORK, and without them it would fail.

    Here's the script, followed by the respective output for a sleep 0
    and sleep 2 runs under linux. I myself have tested this on IRIX 6.2
    as well, with the same results. Of particular interest is the 'B'
    test file at the end of each output.

    Be aware this script should be run in a *test directory*, since
    there are rm -rf commands:

----------- START: This script demonstrates the problem
#!/bin/sh

# test - exposes possible gnu tar incremental bug
# V.1 - spd@daphne.cps.unizar.es
# V.2 - erco@netcom.com - added sleeps
# V.3 - erco@netcom.com - added $TAR

#SLEEP="sleep 2"        # sleep: uncomment this, it FAILS
SLEEP="sleep 0"         # no sleep: uncomment this, it works (sometimes)

TAR=gnutar              # name you call tar 1.12

#V=v                    # verbose
V=""                    # quiet

uname -a | sed -e "s/`hostname`/xxx/" # :-)
$TAR --version | head -1
rm -rf snapshot subdir
mkdir subdir ; touch subdir/a subdir/b subdir/c
echo Full:
$SLEEP
$TAR c${V}sfg /usr/tmp/fulldump.tar snapshot subdir
$SLEEP
rm subdir/a
$SLEEP
mv subdir/b subdir/B
$SLEEP
touch subdir/D
$SLEEP
echo Level 1:
$TAR c${V}sfg /usr/tmp/inc-1.tar snapshot subdir
$SLEEP
echo Subdir:
find subdir -print
rm -rf subdir
echo Full:
$TAR x${V}fsg /usr/tmp/fulldump.tar snapshot
echo Level 1:
$TAR x${V}fsg /usr/tmp/inc-1.tar snapshot
echo Subdir:
find subdir -print
rm -rf snapshot /usr/tmp/fulldump.tar /usr/tmp/inc-1.tar subdir
----------- END

        When I execute this [script] with 'sleep 0' enabled, ie.
        no delay between commands, the 'B' file is CORRECTLY restored:

----------- START: sleep 0 output
Linux xxx 2.0.34 #1 Fri May 8 16:05:57 EDT 1998 i686 unknown
tar-1.12-2
tar (GNU tar) 1.12
Full:
Level 1:
Subdir:
subdir
subdir/B
subdir/D
subdir/c
Full:
Level 1:
Subdir:
subdir
subdir/B  <---- Now you see it..
subdir/D
subdir/c
----------- END

        ..and now again, with 'sleep 2' enabled, causing short
        delays in the time stamps of files. This script does NOT
        restore the 'B' file, which seems WRONG:

----------- START: 'sleep 2' output
Linux xxx 2.0.34 #1 Fri May 8 16:05:57 EDT 1998 i686 unknown
tar-1.12-2
tar (GNU tar) 1.12
Full:
Level 1:
Subdir:
subdir
subdir/B
subdir/D
subdir/c
Full:
Level 1:
Subdir:
subdir
subdir/D  \____ ..now you dont!
subdir/c  /
------------ END

--
Greg Ercolano - SDC Unix Systems Administrator    xxxx: (xxx)-xxx-xxxx
erco@sre.sony.com                                 xxxx: (xxx)-xxx-xxxx

From: Greg Ercolano <erco@sre.sony.com>
To: tar-bugs@gnu.ai.mit.edu
CC: erco@netcom.com, Kay.Diederichs@uni-konstanz.de, spd@daphne.cps.unizar.es
Date: Mon, 12 Oct 1998 17:06:16 -0700
Subject: Re: GNU TAR 1.12: incremental bug report: bug identified?

Follow up regarding the bug I've reported several days ago.
I think I found the bug, or at least a critical section of the
code where the failure is occuring.

BTW, I found it helpful to turn on the verbose option in the
test script I enclosed before to track down the bug.

THE INCREMENTAL BACKUP BUG
--------------------------
The bug appears to be on line 293 of increment.c, tar V 1.12, where
it chooses whether to backup a file or not via the 'Y' or 'N' flag:

    292           if (!all_children
    293               && stat_data.st_mtime < newer_mtime_option
    294               && (!after_date_option
    295                   || stat_data.st_ctime < newer_ctime_option))
    296             add_to_accumulator (accumulator, "N", 1);
    297           else
    298             add_to_accumulator (accumulator, "Y", 1);

This line assumes that a file's mtime has to change relative to
the snapshot file's date stamp for a backup to take place.

The modify time for a file is *not* changed when it is renamed,
so this appears to be the cause of the problem. When the date
stamps are greater than, or especially equal, then the file is
backed up. This is why my test script works when there's no sleeps,
since the date stamps are THE SAME, failing the test in 293.

To correct the problem, if the modify time is LESS than the snapshot
file, but the filename is NOT in the list of files that have already
been backed up, then it SHOULD be backed up.

I do not have a fix, since I don't know all the ins and outs of
diving through the snapshot file.

INCREMENTAL TEST SCRIPT BUGS/ADDITIONS NEEDED
---------------------------------------------
Also, one problem is that the incremental test script is
NOT failing, and it should be.

One reason is there is only one sleep command in the script. 
To answer the question posed by the comment within that script:

--------
# FIXME: The sleep is necessary for the second tar to work.  Exactly why?
sleep 1
--------

The answer is (I think), that sleep command synchronizes the clock
so that, if the rest of the commands execute within a second, the bug
does not surface! That is one reason why the test passes. 

Several things should be added to the incremen.sh script to correctly
test gnutar incrementals:

    1) It should at LEAST do a 'sleep 1' (if not 'sleep 2') after EACH tar
       command, or any command that modifies the file system such as with 
       touch or rename.

    2) The test should include files that are *renamed* after the
       level0 backup, but before the incremental.

I hope these suggestions help you towards fixing this problem.

As it is, we here at Sony don't trust the incremental backups
for this reason until the bug is fixed.

--
Greg Ercolano - SDC Unix Systems Administrator    xxxx: (xxx)-xxx-xxxx
erco@sre.sony.com                                 xxxx: (xxx)-xxx-xxxx