MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0011176CMakeCMakepublic2010-08-26 13:382012-05-27 07:52
ReporterBrad King 
Assigned ToBrad King 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake-2-8 
Target VersionCMake 2.8.3Fixed in VersionCMake 2.8.3 
Summary0011176: "cmake -E tar" encodes long paths such that Fedora GNU tar 1.15.1 reports errors
DescriptionForking orthogonal issue out of 0011020.

There are older versions of tar which choke on the extensions which libarchive is now using.

See e.g. http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2007-05/msg00700.html [^] [^]

tar outputs:
tar: Ignoring unknown extended header keyword `SCHILY.dev'
tar: Ignoring unknown extended header keyword `SCHILY.ino'
tar: Ignoring unknown extended header keyword `SCHILY.nlink'
tar: Ignoring unknown extended header keyword `LIBARCHIVE.xattr.security.selinux'

... and finally exits with code 2 (instead of just issuing a warning and exiting with 0).
Steps To Reproduce
Additional InformationSource for tar showing problem:

http://archives.fedoraproject.org/pub/archive/fedora/linux/releases/7/Fedora/source/SRPMS/tar-1.15.1-26.fc7.src.rpm [^]

We're using the pax format through libarchive:

  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=22fb266d [^]
TagsNo tags attached.
Relationships
related to 0011020closed Brad King CPack produces uninstallable DEB files with 2.8.2, worked with 2.8.1 
related to 0011958closed Brad King libarchive still produces PAX tar archives which are unreadable on older versions of tar 
related to 0013251closed Brad King cmake -E tar <file> fails to extract some files correctly 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2010-08-26 13:38Brad KingNew Issue
2010-08-26 13:38Brad KingRelationship addedrelated to 0011020
2010-08-26 13:38Brad KingStatusnew => assigned
2010-08-26 13:38Brad KingAssigned To => Brad King
2010-08-26 13:53Brad KingNote Added: 0021978
2010-08-26 14:14Brad KingNote Added: 0021979
2010-08-27 04:39simonhNote Added: 0021986
2010-08-27 09:09Brad KingNote Added: 0021989
2010-08-27 09:24Brad KingNote Added: 0021990
2010-09-08 10:51Brad KingStatusassigned => closed
2010-09-08 10:51Brad KingResolutionopen => fixed
2010-09-10 00:12David ColeFixed in Version => CMake 2.8.3
2010-09-10 00:12David ColeTarget Version => CMake 2.8.3
2011-03-10 07:29Brad KingRelationship addedrelated to 0011958
2012-05-27 07:52Eric NOULARDRelationship addedrelated to 0013251

Notes
(0021978)
Brad King   
2010-08-26 13:53   
It looks like libarchive recently discussed some changes for this:

http://groups.google.com/group/libarchive-discuss/browse_thread/thread/4fa233df85fc5e49 [^]
(0021979)
Brad King   
2010-08-26 14:14   
http://code.google.com/p/libarchive/source/detail?r=2563 [^]
(0021986)
simonh   
2010-08-27 04:39   
The upstream patch is fine as far as it goes, but we're still going to get the LIBARCHIVE extended header keyword, so tar 1.15.1 will still choke.
(0021989)
Brad King   
2010-08-27 09:09   
FYI, CMake 'master' now supports building against a system-installed libarchive.

I managed to build from tar-1.15.1-26.fc7.src.rpm with all the patches applied and reproduced the problem:

tar: Ignoring unknown extended header keyword `SCHILY.dev'
tar: Ignoring unknown extended header keyword `SCHILY.ino'
tar: Ignoring unknown extended header keyword `SCHILY.nlink'
...
tar: Error exit delayed from previous errors

Then I built libarchive from svn trunk (r2563) and installed it to a test location. I built CMake against this version and created a tarball with a 900-character path. The above-mentioned tar extracts it correctly.
(0021990)
Brad King   
2010-08-27 09:24   
I committed the upstream patch to CMake's libarchive:

  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e87b6bbd [^]