Sergey Poznyakoff wrote:
Peter Kronheimer <[EMAIL PROTECTED]> wrote:If an existing non-empty directory is deleted and then replaced by a symbolic link (with the same name) pointing to a new target, then the listed-incremental mechanism fails, at least with version 1.15.1.The listed-incremental mechanism is (mainly) based on comparing mtimes of the files in the previous backup with the mtimes of the existing files, therefore the proposed testcase is destined to fail at about 50% of runs. Tar will be able to catch the following change: rm -r testbackup/bar mkdir bar-target ln -s $HOME/tmp/bar-target testbackup/bar only if enough time has elapsed between rm and ln for the mtime of testbackup to change. So, its a toss-up depending on the underlying filesystem timestamp resolution. On my box, 100 runs of the supplied script produced 54 failures and 46 successes. Inserting a `sleep 1' between `rm' and `mkdir' makes the testcase produce 100% of successes.
Hmmm. Turning that transcript into a script (see below) and running it on my system gives failure 100% of the time: no successes. Adding a "sleep 1" didn't make any difference. My filesystem is ext3 under linux on x86.
Have there been relevant changes in gnu tar, since version 1.15.1, which might account for this?
test-tar.sh
Description: application/shellscript
_______________________________________________ Bug-tar mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-tar
