If you perform a full system backup as follows: rm -f stamp tar -c -f /dev/tape --listed-incremental=stamp -l / /boot /home /usr /usr/beam /src1 /src2 /src3 /scratch Then if you perform an incremental backup using tar -c -f /dev/tape --listed-incremental=stamp -l / /boot /home /usr /usr/beam /src1 /src2 /src3 /scratch It appears that the incremental proceeds to copy almost all of the files including ones that have not changed. It appears that the stamp file does not contain all of the directories backed up in the full backup. Redhat 6.1 was fine ... This may only occur with a large number of paths ???
Please check if this still occurs with 1.13.18-1 (Rawhide); can't reproduce it here. (Maybe I didn't have a sufficient number of directories though).
The same problem appears with tar-1.13.17-3 on Redhat 6.2 (again: 6.1 is ok): Time for an updated tar for the RH 6 series?
I have just got around to looking a bit more at this bug with the RedHat 7.2 release installed using tar version 1.13.19-6. Tar is still VERY broken when the --listed-incremental=<file> option is used with a number of directory arguments on our system which has a large number of files. In fact if a full backup is done using this tar less that 1/4 of the systems files are backed up with no error messages from tar ! I have tried the stock Gnu tar 1.13 and this work fine. I am going to start by looking at the patches to the stock Gnu tar but is it worth trying the RawHide 1.13.25-3 release instread ? A warning should be put in the RedHat errata site about this bug as it is very dangerous.
I have found this problem is releated to the -l and --listed-incremental or -g options being used together. I have reduced the problem to a simple demonstration with tar 1.13.19-6. 1. Create a directory and cd there. 2. Create two directories a and b 3. Create a simple file system (dd if=/dev/zero of=fs count=1000; mke2fs -F fs) 4. Mount this filesystem on b (mount -o loop fs b) 5. Create some files: (echo "Hi" > a/file; echo "Hi" > b/file) 6. Try the tar (rm -f s; tar -clf - -g s . ./b | tar -tf -) This will show that the file a/file is stored but not the file b/file.
I have tracked this problem a little further. It appears to come from the collect_and_sort_names function in names.c. What appears to happen is this: Assume the command "tar -clf - -g stamp / /home | tar -tf -" where /home is a mounted file system on a different device. Tar appears to search for directories on / and caches information on them (note_directory etc). When it sees /home it .sees this is on another device and marks it in the cache with the parameter children option set to NO_CHILDREN. When tar gets around to looking at the /home tree it ignores it because the directory is in the cache and marked as NO_CHILDREN. As this code is critical and I am not up to speed on tar I do not have a patch to fix this. As a matter of interest where does the original source code come from ? ftp://ftp.gnu.org/pub/gnu/tar/tar-1.13.19.tar.bz2 does not seem to exist.
You can download tar-1.13.x at ftp://alpha.gnu.org/gnu/tar/ For now: 1.13.7 works and 1.13.25 does not. I'll try to narrow it down (any help is appreciated ;))
It seems, the bug appeared in tar-1.13.18.
I'm completly confused. There are 2 different problems, aren't the. 1,Terry Barnaby (terry1.uk) on 2001-01-19 13:12 -tar archieved files that have not changed -i'm having problem reproduce this bug. 2,Terry Barnaby (terry1.uk) on 2002-01-28 09:33 -"-l" options cause staying in local file system when creating an archive, so file b/file can not be stored.