Description of problem: extracting with 'tar --files-from' do not recurse on directory It should behave like the name are on the command line argument. Version-Release number of selected component (if applicable): tar-1.28-3.fc22.x86_64 How reproducible: Steps to Reproduce: 1. mkdir tt 2. cd tt 3. mkdir foo 4. touch bar 5. tar cvf ../foo.tar . 6. tar tf ../foo.tar ./foo ./foo/ ./foo/bar # both files are listed when on command line argument 7. echo ./foo > ../list 8. tar tf ../foo.tar --files-from ../list ./foo/ # only ./foo is listed whenusing --files-from Actual results: The contents of a directory is not listed/extracted Expected results: The contents of the directory should be listed and/or extracted Additional info: tar-1.28 works: tar-1.28/src/tar tf ../foo.tar --files-from ../list ./foo/ ./foo/bar tar-git works: 15c02c2b9d383446b3ea35dbea5a048e136b020d tar-git/src/tar tf ../foo.tar --files-from ../list ./foo/ ./foo/bar This bug break the amanda backup software since it use --files-from to extract directories.
Thanks for the report. (In reply to Jean-Louis Martineau from comment #0) > Steps to Reproduce: > 1. mkdir tt > 2. cd tt > 3. mkdir foo > 4. touch bar s|touch bar|touch foo/bar| > 5. tar cvf ../foo.tar . > 6. tar tf ../foo.tar ./foo > ./foo/ > ./foo/bar # both files are listed when on command line argument > 7. echo ./foo > ../list > 8. tar tf ../foo.tar --files-from ../list > ./foo/ # only ./foo is listed whenusing --files-from > > Actual results: > The contents of a directory is not listed/extracted > Additional info: > tar-1.28 works: > tar-1.28/src/tar tf ../foo.tar --files-from ../list > ./foo/ > ./foo/bar Hmm, this does not seem to be truth. I have just tried freshly built tar 1.28 and it does not work for me in this case. Jean-Louis, can you please check again? IMHO, git tar is OK because of this (post v1.28) commit: http://git.savannah.gnu.org/cgit/tar.git/commit/?id=163e96a0e619a900eab6de
Ok, I see you are original upstream reporter, clearing needinfo http://www.mail-archive.com/bug-tar@gnu.org/msg04623.html There has been reported issue with the proposed patch by guys from Suse, which in turn forced them to revert the backported patch http://www.mail-archive.com/bug-tar@gnu.org/msg04750.html I need to do better analysis before I'll think about backporting.
(In reply to Pavel Raiskup from comment #2) > Ok, I see you are original upstream reporter, clearing needinfo > http://www.mail-archive.com/bug-tar@gnu.org/msg04623.html By this ^^ I meant that you are definitely aware that upstream fixed this issue post v1.28 release. > There has been reported issue with the proposed patch by guys from Suse, > which in turn forced them to revert the backported patch > http://www.mail-archive.com/bug-tar@gnu.org/msg04750.html > > I need to do better analysis before I'll think about backporting. FYI, I commented directly in the upstream thread. To me, there does not seem to be serious issue. It rather looks OpenSuse guys misinterpreted the expected change as regression. I am in favour of back-porting the fix into F21+ as there is no obvious work-around amanda could use now.
tar-1.28-6.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/tar-1.28-6.fc22
tar-1.27.1-8.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/tar-1.27.1-8.fc21
Package tar-1.27.1-8.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing tar-1.27.1-8.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-10829/tar-1.27.1-8.fc21 then log in and leave karma (feedback).
tar-1.28-6.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
tar-1.28-6.fc22 seems to break the command "dpkg-deb". dpkg-deb now includes the "DEBIAN" directory (containing the maintenance scripts of the package) into the data-archive. Because of this, when installing the package, the DEBIAN-directory gets copied to the root of the file system. This currently breaks our build process.
dpkg-build calls tar with the following parameters (copied from build.c): execlp(TAR, "tar", "-cf", "-", "--format=gnu", "--null", "--no-unquote", "-T", "-", "--no-recursion", NULL); Maybe -T does not work correctly when used together with "--no-recursion"?
Christian, ideally - dpkg-build should call tar binary with specified --no-recursion before '-T -'. This is semantics which was backported in this bug -- and its the expected behavior of tar. Any new release of GNU tar will behave like that -- so sooner dpkg-build will be fixed, the better.
(In reply to Pavel Raiskup from comment #10) > Christian, ideally - dpkg-build should call tar binary with specified > --no-recursion before '-T -'. This is semantics which was backported in > this bug -- and its the expected behavior of tar. Any new release of GNU > tar will behave like that -- so sooner dpkg-build will be fixed, the better. and on epel6 and epel7 ? dpkg-build should we do the same ?
(In reply to Sergio Monteiro Basto from comment #11) > and on epel6 and epel7 ? dpkg-build should we do the same ? As tar is not fixed in RHEL{6,7}, there is no need to backpatch dpkg in epel. On the other hand, it may be fixed (via future rebase? because this needs to be fixed upstream also).
(In reply to Pavel Raiskup from comment #12) > On the other hand, it may be fixed (via future rebase? because this needs > to be fixed upstream also). Yes, I will contact upstream to include this patch in future releases, if isn't already done. I will check that .
tar-1.27.1-8.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
Hi, (In reply to Sergio Monteiro Basto from comment #13) > (In reply to Pavel Raiskup from comment #12) > > On the other hand, it may be fixed (via future rebase? because this needs > > to be fixed upstream also). > > Yes, I will contact upstream to include this patch in future releases, if > isn't already done. I will check that . I wrote to debian-dpkg Mailing List (debian-dpkg.org) [1] and Guillem Jover wrote: "Right, this was reported to me some time ago by Richard Purdie, and got already fixed in 1.18.2, for both the dpkg-deb issue and a potential similar issue I noticed in the perl modules: <http://anonscm.debian.org/cgit/dpkg/dpkg.git/commit/?id=fcfe4f3aa2f3cb7f8179d4f2fe6dd65e75f7bbdf> <http://anonscm.debian.org/cgit/dpkg/dpkg.git/commit/?id=02e2060504f1c8dbbe5dec8211beaf945350c789> My plan was to keep it in 1.18.x for a bit, to get it tested, and then backport it to the 1.16.x and 1.17.x branches." So patch is already upstreamed ! Thanks, [1] http://www.eenyhelp.com/answer/patch-tar-exec-use-no-recursion-before-t-option-help-215780194.html#r