+++ This bug was initially created as a clone of Bug #634866 +++

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.

--- Additional comment from kdudka on 2010-09-17 11:52:13 CEST ---

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.

--- Additional comment from kdudka on 2010-09-17 12:01:01 CEST ---

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

--- Additional comment from kdudka on 2010-09-17 12:13:34 CEST ---

/* Some constants from POSIX are given names.  */
#define NAME_FIELD_SIZE   100

--- Additional comment from albrecht.dress on 2010-09-17 12:41:08 CEST ---

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...

--- Additional comment from kdudka on 2010-09-17 13:06:01 CEST ---

Created attachment 447974 [details]
work in progress

not yet tested if it doesn't break something

--- Additional comment from kdudka on 2010-09-17 13:17:02 CEST ---

(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)

--- Additional comment from kdudka on 2010-09-17 13:54:14 CEST ---

upstream patch:

http://git.savannah.gnu.org/gitweb/?p=tar.git;a=commitdiff;h=9c194c9

--- Additional comment from kdudka on 2010-09-17 13:58:30 CEST ---

Created attachment 447978 [details]
backport for tar-1.22

--- Additional comment from kdudka on 2010-09-20 10:44:50 CEST ---

fixed in tar-1.23-6.fc15

--- Additional comment from albrecht.dress on 2010-09-20 15:03:35 CEST ---

(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?

--- Additional comment from kdudka on 2010-09-20 15:19:41 CEST ---

(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

--- Additional comment from updates on 2010-09-20 22:06:24 CEST ---

tar-1.23-5.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/tar-1.23-5.fc14

--- Additional comment from updates on 2010-09-20 22:41:52 CEST ---

tar-1.22-18.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/tar-1.22-18.fc13

--- Additional comment from updates on 2010-09-21 03:33:07 CEST ---

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

--- Additional comment from updates on 2010-09-23 06:54:15 CEST ---

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.

--- Additional comment from updates on 2010-09-23 14:52:46 CEST ---

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.