Description of problem: The 'tar' version coming with Fedora fails to extract single files from an archive if the paths grow long. This behaviour does not occur with the original GNU tar. Version-Release number of selected component (if applicable): [albrecht@pc-adr2v3 ~]$ tar --version tar (GNU tar) 1.22 How reproducible: Always. Steps to Reproduce: 1. Create a tar: [albrecht@pc-adr2v3 ~]$ tar --xattrs --create --file ~/TEST.tar --directory /home/albrecht ./Work/.metadata/.plugins/org.eclipse.ltk.core.refactoring/.refactorings/.workspace/2010/9/37 2. Verify the contents of the archive: [albrecht@pc-adr2v3 ~]$ tar -tf TEST.tar ./Work/.metadata/.plugins/org.eclipse.ltk.core.refactoring/.refactorings/.workspace/2010/9/37/ ./Work/.metadata/.plugins/org.eclipse.ltk.core.refactoring/.refactorings/.workspace/2010/9/37/refactorings.history ./Work/.metadata/.plugins/org.eclipse.ltk.core.refactoring/.refactorings/.workspace/2010/9/37/refactorings.index 3. Try to extract one single file with a rather long path: [albrecht@pc-adr2v3 ~]$ tar --xattrs -xvpf ~/TEST.tar ./Work/.metadata/.plugins/org.eclipse.ltk.core.refactoring/.refactorings/.workspace/2010/9/37/refactorings.history tar: ./Work/.metadata/.plugins/org.eclipse.ltk.core.refactoring/.refactorings/.workspace/2010/9/37/refactorings.history: Not found in archive tar: Exiting with failure status due to previous errors 4. Extract the full folder works: [albrecht@pc-adr2v3 ~]$ tar --xattrs -xvpf ~/TEST.tar ./Work/.metadata/.plugins/org.eclipse.ltk.core.refactoring/.refactorings/.workspace/2010/9/37 ./Work/.metadata/.plugins/org.eclipse.ltk.core.refactoring/.refactorings/.workspace/2010/9/37/ ./Work/.metadata/.plugins/org.eclipse.ltk.core.refactoring/.refactorings/.workspace/2010/9/37/refactorings.history ./Work/.metadata/.plugins/org.eclipse.ltk.core.refactoring/.refactorings/.workspace/2010/9/37/refactorings.index Actual results: See step 3 above - extract fails. Expected results: The extract should work. Additional info: I tried the same on Ubuntu 10.04 which uses the original GNU tar (which does not support the '--xattrs' command line switch, i.e. it does not store any extended attributes). There, step #3 *does* properly extract the single file.
Thank you for reporting the bug! It works also on Fedora if you don't use --xattrs, so there seems to be some limitation of the xattr patch involved.
Length of the file name is truncated to 100 chars for some reason: $ gdb -q --args tar -xf ~/TEST.tar ./Work/.metadata/.plugins/org.eclipse.ltk.core.refactoring/.refactorings/.workspace/2010/9/37/refactorings.history (gdb) break list.c:92 Breakpoint 1 at 0x41690c: file list.c, line 92. (gdb) run Breakpoint 1, read_and (do_something=0x40d440 <extract_archive>) at list.c:92 92 if (! name_match (current_stat_info.file_name) (gdb) display current_stat_info.file_name (gdb) display strlen(current_stat_info.file_name) (gdb) next 105 switch (current_header->header.typeflag) 2: strlen(current_stat_info.file_name) = 93 1: current_stat_info.file_name = 0x85a5b0 "./Work/.metadata/.plugins/org.eclipse.ltk.core.refactoring/.refactorings/.workspace/2010/9/37" (gdb) cont Breakpoint 1, read_and (do_something=0x40d440 <extract_archive>) at list.c:92 92 if (! name_match (current_stat_info.file_name) 2: strlen(current_stat_info.file_name) = 100 1: current_stat_info.file_name = 0x85a0c0 "./Work/.metadata/.plugins/org.eclipse.ltk.core.refactoring/.refactorings/.workspace/2010/9/37/refact" (gdb) cont Breakpoint 1, read_and (do_something=0x40d440 <extract_archive>) at list.c:92 92 if (! name_match (current_stat_info.file_name) 2: strlen(current_stat_info.file_name) = 100 1: current_stat_info.file_name = 0x85ae30 "./Work/.metadata/.plugins/org.eclipse.ltk.core.refactoring/.refactorings/.workspace/2010/9/37/refact" (gdb) cont /bin/tar: ./Work/.metadata/.plugins/org.eclipse.ltk.core.refactoring/.refactorings/.workspace/2010/9/37/refactorings.history: Not found in archive /bin/tar: Exiting with failure status due to previous errors
/* Some constants from POSIX are given names. */ #define NAME_FIELD_SIZE 100
I see. I get the same error on Ubuntu's tar when I create an archive with the '--posix' option. If '--xattrs' implies '--posix', this issue would be a feature instead of a bug. However, it would be *really* great if the limitation could be removed for the 'gnu' format. The practical background: I use Amanda as backup tool. When I need to restore a file as in the example, amanda (which in turn calls tar) fails to extract with the 'Not found in archive' error. I then have to extract a *complete* parent folder with a shorter name (shorter than 100 chars) to some temp space (as I don't want to overwrite other files), and then move the files manually. Needless to say that this is really uncomfortable...
Created attachment 447974 [details] work in progress not yet tested if it doesn't break something
(In reply to comment #5) > not yet tested if it doesn't break something It breaks handling of sprase files: 57: sparse files FAILED (sparse01.at:24) 58: extracting sparse file over a pipe FAILED (sparse02.at:28) 59: storing sparse files > 8G FAILED (sparse03.at:29) 60: sparse files in MV archives FAILED (sparsemv.at:31) 61: sparse files in PAX MV archives, v.0.0 FAILED (spmvp00.at:24) 62: sparse files in PAX MV archives, v.0.1 FAILED (spmvp01.at:24) 63: sparse files in PAX MV archives, v.1.0 FAILED (spmvp10.at:24)
upstream patch: http://git.savannah.gnu.org/gitweb/?p=tar.git;a=commitdiff;h=9c194c9
Created attachment 447978 [details] backport for tar-1.22
fixed in tar-1.23-6.fc15
(In reply to comment #8) > Created attachment 447978 [details] > backport for tar-1.22 I re-built tar with this patch, and tried an "extract" from Amanda using the new binary. The extract of single files with long names (>100 chars) does now work as expected, so afaict the solution seems to fix the issue (note that Amanda always uses the "--sparse" option when it creates tar's). Do you also plan to release an "official" fixed package for FC13?
(In reply to comment #10) > I re-built tar with this patch, and tried an "extract" from Amanda using the > new binary. The extract of single files with long names (>100 chars) does now > work as expected, so afaict the solution seems to fix the issue (note that > Amanda always uses the "--sparse" option when it creates tar's). Thank you for testing the patch! > Do you also plan to release an "official" fixed package for FC13? Sure, will be available later this week. All necessary changes are already pushed into Fedora git, now I am just waiting for response from upstream with another patch, in order to reflect their review comments in our packages eventually: http://lists.gnu.org/archive/html/bug-tar/2010-09/msg00066.html
tar-1.23-5.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/tar-1.23-5.fc14
tar-1.22-18.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/tar-1.22-18.fc13
tar-1.22-18.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update tar'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/tar-1.22-18.fc13
tar-1.22-18.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
tar-1.23-5.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.