Sparse files in tars are a GNU extension that libarchive will use if it
detects holes in the input file, even when using the standard pax/paxr
formats. Not all tar implementations can handle sparse files; in particular,
the internal implementation dpkg uses to extract packages can't. To
maximize archive portability, turn this feature off by clearing the
sparseness information from archive entries.
The libarchive APIs use nl_langinfo(CODESET) for iconv so they need the
locale to be set for LC_CTYPE. However, the rest of CMake does not
define any behavior for non-ASCII character classification/conversion so
we do not want to setlocale() globally. Add a RAII class to save, set,
and restore the locale around calls to libarchive APIs.
Inspired-by: Clinton Stimpson <clinton@elemtech.com>
Add an option to set the mtime of entries in a tarball so that one can
create a tarball with a consistent content hash (e.g. MD5) for a given
set of files regardless of their current timestamps on disk. This will
be useful for submission of tarballs to CDash, which tracks content
hashes to avoid duplication.
Inspired-by: Bill Hoffman <bill.hoffman@kitware.com>
Because the 8bit string encoding in libarchive can be different than
the 8bit string encoding in CMake, change to call the wide version
of libarchive functions. They are different if CMake is configured
to use UTF-8 as the internal encoding.
Create helper functions for some libarchive calls to use wstring
internally on platforms supporting it.
When reading archive entries from disk strip any "fflags" entry headers
that may have been loaded from the filesystem when libarchive is built
with HAVE_STRUCT_STAT_ST_FLAGS (struct stat has 'st_flags'). The local
filesystem flags are not useful for distribution. Furthermore, GNU tar
does not understand the "SCHILY.fflags" extended header used to store
the flags in the archive. Use the approach from commit e8558efa
(cmArchiveWrite: Clear xattr and acl from entries, 2011-04-07) to remove
the flags and avoid producing the non-portable extended header.
This wasn't necessary for TAR-like (TGZ, TBZ2, etc...) archive
because for those the size was 0. Either there is an error in
upstream libarchive concerning the size or we should not rely
on size of the entry for adding content.
Do not recurse through directory symlinks when adding files.
Recursing through directory symlinks will generate broken archives,
i.e., they will look something like this:
foo -> bar/bar
foo/Info <- Shouldn't be in archive.
bar/bar
bar/bar/Info
When reading archive entries from disk strip any xattr and acl entry
headers that may have been loaded from the filesystem (e.g. selinux).
These fields are only useful for backup tools and not for packaging and
distribution of software. Furthermore, the GNU tar 1.15.1 on at least
one Linux distribution treats unknown entry headers as an error rather
than a warning. Therefore avoiding such fields is necessary for archive
portability.
Suggested-by: Tim Kientzle <tim@kientzle.com>
This is not needed but it does not cost much to do it for all
potentially supported format in libarchive. XZ and LZMA are not
builtin libarchive and require external lib but if
CMAKE_USE_SYSTEM_LIBARCHIVE is ON then we may get it for free.
This will be needed to use cmArchiveWrire in cmCPackArchiveGenerator
with the same feature set as before. Note that adding zip
support to libarchive-wrapper would also makes it easy to add
a new -E zip command to cmake commands.
Some stream libraries return size_t from gcount() and some return
ssize_t. Add an explicit cast to ios::streamsize for its return value.
Also refactor use of nnext to reduce the use of casts.
The libarchive interface accepts size_t but returns ssize_t. The std
streams interface wants streamsize, which is typically ssize_t. Since
no one type for our variable matches without conversions, make the
conversions explicit to avoid -Wsign-conversion and -Wsign-compare
warnings.
