Red Hat Bugzilla – Bug 1184697
RHEL7 tar doesn't restore incremental backup correctly.
Last modified: 2017-08-01 13:01:03 EDT
Description of problem: When RHEL7 tar restoring incremental backup, it doesn't remove a file that removed from previous backup. Version-Release number of selected component (if applicable): tar-1.26-29.el7 How reproducible: Always Steps to Reproduce: 1. Get files ready for archive. # pwd /var/tmp # ls tmp 1.txt 2.txt 2. Creating a full backup archive. # tar Jcfg file.tar.xz file.snar tmp # tar Jtf file.tar.xz tmp/ tmp/1.txt tmp/2.txt 2. Creating an incremental backup archive. # echo 3 > tmp/3.txt # rm tmp/2.txt # tar Jcfg file2.tar.xz file.snar tmp 3. Restore files from full backup archive. # mkdir file # tar JxfCg file.tar.xz ./file/ file.snar # find file/ file/ file/tmp file/tmp/1.txt file/tmp/2.txt 4. Restore files from incremental backup archive. # tar JxfCg file2.tar.xz file/ file.snar Actual results: RHEL7 tar does not remove file "2.txt". # tar JxfCg file2.tar.xz file/ file.snar # find file/ file/ file/tmp file/tmp/1.txt file/tmp/2.txt file/tmp/3.txt Expected results: tar can remove file "2.txt" like RHEL6. # tar JxfCg file2.tar.xz file/ file.snar # find file/ file/ file/tmp file/tmp/1.txt file/tmp/3.txt
Thanks for the report and sorry for the delay. Yes, that was/is bug in upstream release 1.26, fixed in 1.27 by upstream commit: http://git.savannah.gnu.org/cgit/tar.git/commit/?id=738fb9c2f44e More concretely, it is a bug in -C option (not the first one relevant to *at() change). You can work-around that by wrapping tar into 'cd file/' and 'cd -', the following example should work for your concrete example: Old command: $ tar JxfCg file.tar.xz ./file/ file.snar New cmomands: $ cd file \ && tar Jxfg ../file.tar.xz ../file.snar \ && cd - Pavel
Created attachment 989672 [details] backpatched fix
I see the customer case is closed now, and I don't know whether this is still expected to be fixed (and I'm considering closing this bug). Was the workaround helpful so we don't need to have this fixed?
(In reply to Pavel Raiskup from comment #4) > I see the customer case is closed now, and I don't know whether this is still > expected to be fixed (and I'm considering closing this bug). > > Was the workaround helpful so we don't need to have this fixed? IMHO we should fix this anyways, this is minimal effort as tar will have an erratum anyways, the patch is ready and there's complete reproducer available for QA
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:2012