Bug 768724 - tar does not extract files with names not matching the current locale
Summary: tar does not extract files with names not matching the current locale
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: tar
Version: 6.2
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Pavel Raiskup
QA Contact: Branislav Blaškovič
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-12-18 11:26 UTC by Peter Klotz
Modified: 2012-06-20 13:49 UTC (History)
3 users (show)

Fixed In Version: tar-1.23-4.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-20 13:49:33 UTC
Target Upstream Version:


Attachments (Terms of Use)
tar file that demonstrates the bug (10.00 KB, application/x-tar)
2011-12-18 11:26 UTC, Peter Klotz
no flags Details
proposed fix (4.23 KB, patch)
2012-01-16 12:00 UTC, Kamil Dudka
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:0849 0 normal SHIPPED_LIVE tar bug fix and enhancement update 2012-06-19 20:48:42 UTC

Description Peter Klotz 2011-12-18 11:26:28 UTC
Created attachment 548372 [details]
tar file that demonstrates the bug

Description of problem:

tar 1.23 (RHEL 6.2) does not extract files that contain characters that do not match the current locale. It only happens if a directory is given that is to be extracted.

Version-Release number of selected component (if applicable):

tar 1.23

How reproducible:
Always

Steps to Reproduce:
1. Call "tar xf 100.tar 100" to extract directory "100" from attached tar file
2. 
3.
  
Actual results:
One only obtains "100/file2a" and "100/md5sums" but not file "100/file1ä".

When called with "tar xf 100.tar" without specifying a directory, all three files are extracted.
It seems that pattern matching fails for the file containing the ISO8859-1 character when tar is run in an UTF-8 environment.

Expected results:
All 3 files should be extracted.

Additional info:
tar 1.15.1 (RHEL 5.7) and tar 1.26 (Upstream) work correctly and extract all three files.

Comment 2 Kamil Dudka 2011-12-18 12:54:53 UTC
This behavior is caused by the implementation of fnmatch() from glibc.  A possible fix would be to switch tar to use the fnmatch implementation from gnulib, which is already there but not used.

Luckily, in your case you do not use the wildcard matching anyway.  So I would suggest to just disable the wildcard matching by the --no-wildcards option.  Note that --no-wildcards is now the default behavior in the upstream tar.

Comment 3 Peter Klotz 2011-12-19 07:30:32 UTC
Thanks Kamil.

I was not even aware of wildcard matching being used in my case.

Since for me a workaround exists, I can deal with this behavior of tar.

It may however break existing scripts that are not that simple to fix.

Comment 6 Kamil Dudka 2012-01-16 12:00:04 UTC
Created attachment 555480 [details]
proposed fix

Sync the assertions about working fnmatch() with up2date tar.  This patch causes the autoconf checks to detect the fnmatch() implementation from RHEL-6 glibc as broken and use the fnmatch() implementation from gnulib instead.

Comment 12 errata-xmlrpc 2012-06-20 13:49:33 UTC
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.

http://rhn.redhat.com/errata/RHBA-2012-0849.html


Note You need to log in before you can comment on or make changes to this bug.