This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 24380 - Tar with --listed-incremental=<file> appears broken
Tar with --listed-incremental=<file> appears broken
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: tar (Show other bugs)
7.0
i386 Linux
high Severity high
: ---
: ---
Assigned To: Peter Vrabec
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-01-19 13:12 EST by Terry Barnaby
Modified: 2005-10-31 17:00 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-25 07:18:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Terry Barnaby 2001-01-19 13:12:46 EST
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 ???
Comment 1 Bernhard Rosenkraenzer 2001-01-24 14:22:08 EST
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).
Comment 2 Need Real Name 2001-08-14 01:15:38 EDT
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?
Comment 3 Terry Barnaby 2002-01-25 11:04:39 EST
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.
Comment 4 Terry Barnaby 2002-01-28 09:33:12 EST
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.
Comment 5 Terry Barnaby 2002-01-29 04:46:06 EST
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.
Comment 6 Olivier Baudron 2002-06-17 17:10:37 EDT
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 ;))
Comment 7 Olivier Baudron 2002-06-17 17:29:47 EDT
It seems, the bug appeared in tar-1.13.18.
Comment 8 Peter Vrabec 2004-10-25 07:18:32 EDT
I'm completly confused. There are 2 different problems, aren't the.
1,Terry Barnaby (terry1@beam.ltd.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@beam.ltd.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.

Note You need to log in before you can comment on or make changes to this bug.