MantisBT - CMake
View Issue Details
0015499CMake(No Category)public2015-04-07 03:252015-04-10 10:50
Nils Gladitz 
Nils Gladitz 
normalminoralways
closedfixed 
CMake 3.2.1 
CMake 3.3 
0015499: cmake -E tar generated packages with long filenames can not be processed by PHP's PharData
CDash (which uses PharData) can not extract some tar archives as created by cmake -E tar (e.g. from the CTestCoverageCollectGCOV.cmake module).

The issue seems to be with long filenames.
An equivalent archive created by GNU tar can be extracted by PharData.
GNU tar is also able to extract the cmake created tar.
Create an empty file:
Testing/CoverageInfo/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.c.gcov

Archive it:
cmake -E tar cvfj cmake.tar "--mtime=1970-01-01 0:0:0 UTC" Testing

Trying to extract the archive with PharData produces an exception:
phar error: "/path/to/cmake.tar" is a corrupted tar file (checksum mismatch of file "133 path=Testing/CoverageInfo/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx")

phar error: "/home/ngladitz/topic/phar/input/cmake.tar" is a corrupted tar file (checksum mismatch of file "133 path=Testing/CoverageInfo/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx")
No tags attached.
tar cmake.tar (289) 2015-04-07 03:26
https://public.kitware.com/Bug/file/5421/cmake.tar
tar gnutar.tar (246) 2015-04-07 03:27
https://public.kitware.com/Bug/file/5422/gnutar.tar
Issue History
2015-04-07 03:25Nils GladitzNew Issue
2015-04-07 03:26Nils GladitzFile Added: cmake.tar
2015-04-07 03:27Nils GladitzFile Added: gnutar.tar
2015-04-07 05:24Nils GladitzNote Added: 0038456
2015-04-07 06:46Nils GladitzNote Added: 0038458
2015-04-07 08:38Brad KingNote Added: 0038459
2015-04-07 08:46Nils GladitzNote Added: 0038460
2015-04-07 08:58Brad KingNote Added: 0038461
2015-04-07 09:03Nils GladitzNote Added: 0038463
2015-04-07 09:04Brad KingNote Added: 0038464
2015-04-07 09:47Nils GladitzNote Added: 0038465
2015-04-10 10:50Nils GladitzNote Added: 0038485
2015-04-10 10:50Nils GladitzStatusnew => closed
2015-04-10 10:50Nils GladitzAssigned To => Nils Gladitz
2015-04-10 10:50Nils GladitzResolutionopen => fixed
2015-04-10 10:50Nils GladitzFixed in Version => CMake 3.3

Notes
(0038456)
Nils Gladitz   
2015-04-07 05:24   
libarchive does seem to support a multitude of tar (and non-tar) formats for writing.

Perhaps a new --format option could be added to cmake -E tar which could then be passed to archive_write_set_format_by_name()?

The "gnutar" format seems to be able to create an archive readable by PharData (tested with bsdtar based on libarchive).
(0038458)
Nils Gladitz   
2015-04-07 06:46   
I created a topic for this (missing tests):
https://github.com/ngladitz/cmake/tree/tar-write-format [^]
(0038459)
Brad King   
2015-04-07 08:38   
For reference, we switched to the current format from "ustar" here:

 use different tar format to handle longer file names
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=22fb266d [^]

For the ``--format=<format>`` option, let's use the names in the GNU tar man page for those that match the formats we support. Rather than passing the --format= value directly to libarchive, let's enumerate the mapping ourselves so we can document the exact set of supported values. Otherwise we're exposing an internal API that may depend on how libarchive was built.
(0038460)
Nils Gladitz   
2015-04-07 08:46   
GNU tar supports fewer formats than libarchive and perhaps with slightly different semantics.

e.g. there is no 7zip or zip support.
Also the current default of "pax restricted" doesn't have an exact match in GNU tar.

I would vote for using a restricted list of the libarchive names (maybe those I already documented).
(0038461)
Brad King   
2015-04-07 08:58   
Re 0015499:0038460: Sounds good, thanks.
(0038463)
Nils Gladitz   
2015-04-07 09:03   
Thanks.

Where would you rather have the restriction (and perhaps future mapping)?
Should it go into -E tar, cmSystemTools::CreateTar or cmArchiveWrite?

I would prefer the first. E.g. restrict the external interface but leave the internal interface open?
(0038464)
Brad King   
2015-04-07 09:04   
Re 0015499:0038463: I agree. Only the external interface needs to be restricted.
(0038465)
Nils Gladitz   
2015-04-07 09:47   
Thanks. I added the format restriction, cleaned up and merged to next for testing.
(0038485)
Nils Gladitz   
2015-04-10 10:50   
Fixed by
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=d2cc580704fa4e608eae104ce5be211a229b2d64 [^]
and
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=fd04d87323749c15969982d9aa9b72059f33463b [^]