Bug 634866

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.