Kevin Locke [Sat, 11 Jan 2014 23:38:52 +0000 (16:38 -0700)]
[PATCH v3] Add read_concatenated_archives
As discussed in http://code.google.com/p/libarchive/issues/detail?id=348
the read_concatenated_archives option provides functionality similar to
the GNUtar --ignore-zeros option in order to support reading from
archives which have been concatenated together.
Changes in v2:
* Replace recursion with looping for reading concatenated archives.
Changes in v3:
* Improve comments about archive format detection and looping when
reading concatenated archives.
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
Kevin Locke [Sat, 11 Jan 2014 23:35:21 +0000 (16:35 -0700)]
Only consume a second all-null record
Currently any record following an all-null record will be consumed.
This is probably not the intended behavior, as it does not match the
comment and consumes/ignores unexpected and unrecognized data. In
particular, for the read_concatenated_archives case, it could
incorrectly consume a non-null header.
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
Trying to assign -1 (ARCHIVE_READ_FORMAT_ENCRYPTION_DONT_KNOW)
to a data type we're not sure will always be signed is a bad idea
(blew up on ARM, for instance).
NiLuJe [Sun, 22 Dec 2013 23:04:38 +0000 (00:04 +0100)]
More MinGW trickery...
Poor man's attempt at making 4e002d9a92ecd7cec0fb98b0bedbace8aad81f6e
play nice with MinGW.
Dry coded for the fastest solution, there's probably a much better
way to handle that sanely & properly.
Fixes a build failure on MinGW:
CC tar/bsdtar-bsdtar.o
In file included from tar/bsdtar_platform.h:62:0,
from tar/bsdtar.c:26:
./libarchive/archive_entry.h:250:64: error: unknown type name 'BY_HANDLE_FILE_INFORMATION'
__LA_DECL void archive_entry_copy_bhfi(struct archive_entry *, BY_HANDLE_FILE_INFORMATION *);
^
Tim Kientzle [Fri, 20 Dec 2013 05:17:23 +0000 (21:17 -0800)]
Zip and Rar store file times in local time,
so we can't verify them in tests (since the
time varies depending on the time zone where
the tests are being run).
Konrad Kleine [Fri, 13 Dec 2013 08:28:55 +0000 (09:28 +0100)]
Include coverage script if ENABLE_COVERAGE is set
Rather than including the LibarchiveCodeCoverage.cmake file and checking
there if ENABLE_COVERAGE is set, we only include the file if this option
is set in the first place.
Hans Johnson [Thu, 16 May 2013 16:26:46 +0000 (11:26 -0500)]
ENH: Allow fine grained control over dependancies
An end user may want to explicitly avoid using
a feature that can be automatically found on the
build system. This arose when the build machine
had libraries for LZMA but the target machine
did not have those libraries available.
By allowing flags the optional features provided by
LZMA/ZLIB/BZip2/EXPAT/PCREPOSIX/LibGCC
can be explicitly removed (Default behavior is
to use what can be found).
Brad King [Mon, 9 Dec 2013 19:03:43 +0000 (14:03 -0500)]
libarchive: Use ARCHIVE_LITERAL_ULL to add ULL integer suffix
The macro maps to an implementation that works on older compilers when
necessary. Convert the 0ULL literal introduced by commit 6cf33c93
(Issue 320: Rewrite (again) to avoid the left shift that CLang dislikes
so much, 2013-12-07) to use the macro.
Tim Kientzle [Sun, 24 Nov 2013 16:44:34 +0000 (08:44 -0800)]
Issue 332: Be more careful guessing file mode information from
incomplete Zip archives. In particular, some epub files have
0 in the file type part of the mode field.
Konrad Kleine [Wed, 9 Oct 2013 11:53:15 +0000 (13:53 +0200)]
Better archive_read_has_encrypted_entries function
These are the possible return values:
=====================================
ARCHIVE_READ_FORMAT_ENCRYPTION_UNSUPPORTED (-2):
------------------------------------------------
This is the default return value for reader that don't support
encrpytion detection at all. When this value is returned you can be sure
that it will always be returned even on later calls to
archive_read_has_encrypted_entries.
ARCHIVE_READ_FORMAT_ENCRYPTION_DONT_KNOW (-1):
----------------------------------------------
This is the default return value for readers that support encryption. It
means that the reader is not yet ready (e.g. not enough data was read so
far) to say that there are encrypted entries in the archive. Over time
as more data was consumed by a reader this value might change to 0 or 1.
0:
--
No encrypted entries were found yet (maybe there will be one when
reading the next header). When 0 is returned, it might be that on a
later call 1 will be returned.
1:
--
At least one encrypted entry was found. Once 1 is returned. It will
always be returned even if the another entry is not encrypted.
NOTE:
=====
If the metadata/header of an archive is also encrypted, you
cannot rely on the number of encrypted entries. That is why this
function does not return the number of encrypted entries but
just 1 to show that there are some. Also, two distinct readers might
detect the number of entries and their encryption status at different
times. If one reader can say how many files are encrypted after reading
the first header another reader might need more data. In the end the
number of encrypted entries might be the same in two archives while the
appropriate readers output different results at different points in
time. This is more confusing than helpful.
Konrad Kleine [Mon, 1 Jul 2013 15:12:24 +0000 (17:12 +0200)]
Detect encrypted archive entries (ZIP, RAR, 7Zip)
With this change you can detect if an archive entry is encrypted. The
archive formats covered with this change are: ZIP, RAR, and 7zip. Other
formats can be added quite simply by looking at the already supported
formats. For all the already supported formats we have tests that check
if:
* an archive entries's data is encryped (data test)
* an archive entries's metadata is encrypted (header test)
* one file is encrypted while another is not (partially test)
These new functions are introduced.
int archive_read_format_capabilities(struct archive*)
Returns a bitmask of capabilities that are supported by the archive
format reader. If the reader has no special capabilities,
ARCHIVE_READ_FORMAT_CAPS_NONE is returned; otherwise 0 is returned.
You can call this function even before reading the first header from
an archive.
Return Values:
* ARCHIVE_READ_FORMAT_CAPS_ENCRYPT_DATA
The reader supports detection of encrypted data.
* ARCHIVE_READ_FORMAT_CAPS_ENCRYPT_METADATA
The reader supports detection of encrypted metadata (e.g.
filename, modification time, size, etc.)
* ARCHIVE_READ_FORMAT_CAPS_NONE
None of the above capabilities. If this value is returned, this
doesn't mean that the format itself doesn't support any type of
encryption it simply means that the reader is not capable of
detecting it.
int archive_read_has_encrypted_entries(struct archive *)
Returns "true" (non-zero) if the archive contains at least one
encrypted entry, no matter which encryption type (data or metadata)
is used; otherwise 0 is returned.
You should only call this function after reading the first header
from an archive.
NOTE: I'm not sure that this function will stay in for long.
int archive_entry_is_data_encrypted(struct archive_entry*)
Returns "true" (non-zero) if the archive entry's data is encrypted;
otherwise 0 is returned. You can call this function after calling
archive_read_next_header().
int archive_entry_is_metadata_encrypted(struct archive_entry*)
Returns "true" (non-zero) if the archive entry's metadata is
encrypted; otherwise 0 is returned. You can call this function after
calling archive_read_next_header().
int archive_entry_is_encrypted(struct archive_entry*)
Returns "true" (non-zero) if either the archive entry's data and/or
it's metadata is encrypted; otherwise 0 is returned. You can call
this function after calling archive_read_next_header().
If you use archive_read_format_capabilities() in combination with one of
the archive_entry_is_[data|metadata]_encrypted() functions, you can be
sure that you've encountered an encrypted entry. This allows you to
react differently depending on libarchive's return codes. For instance,
you might want to skip encrypted files from being extracted until
decryption support has been implemented.
Here's how I generated the 7zip test files:
-------------------------------------------
Ross Lagerwall [Mon, 16 Sep 2013 06:39:02 +0000 (08:39 +0200)]
Show third party library versions in version string
Add a utility function, archive_version_details, to return a string
containing the libarchive version as well as the versions of third party
libraries such as zlib, bz2lib and liblzma. Use this function for
bsdtar --version and bsdcpio --version.
Konrad Kleine [Thu, 12 Sep 2013 15:01:31 +0000 (17:01 +0200)]
Added all Zip compression names from 6.3.3 format
I've added all the compression names and IDs from the ".ZIP File Format
Specification" version 6.3.3 that can be found in section "4.4.5
compression method" of this document:
Implement "resdevice" and "inode" in the mtree(5) spec.
- resdevice is the keyword that corresponds to the "resident" device,
e.g. the one where the entry resides;
- inode is entry's inode number.
Start implementing the "resdevice" (resident device) keyword. It
corresponds to the st_dev field of stat(2), e.g. the ID of the
device that contains the inode.
Change parse_device() prototype so it can be used for "device"
and "resdevice", and call the appropriate archive_entry_set_{,r}dev()
function to store the field value.
Add the device parsing logic. It allows mtree's libarchive to
parse device entries like NetBSD's mtree and its multiple possible
format: native, 386bsd, 4bsd, bsdos, freebsd, hpux, isc, linux, netbsd,
osf1, sco, solaris, sunos, svr3, svr4, and ultrix.
Terrell Russell [Tue, 30 Jul 2013 18:52:24 +0000 (14:52 -0400)]
include linux/types.h on CentOS 5 in test_sparse_basic.c
Was getting this error:
In file included from ....../libarchive-3.1.2/libarchive/test/test_sparse_basic.c:44:
/usr/include/linux/fiemap.h:15: error: expected specifier-qualifier-list before ‘__u64’
/usr/include/linux/fiemap.h:26: error: expected specifier-qualifier-list before ‘__u64’
From https://groups.google.com/forum/#!msg/libarchive-discuss/691PHz5ENOc/4OzXBevG75AJ I see that the <linux/types.h> file is not included.
This fixed the problem for me on CentOS 5.8.
It was not visible as an issue on CentOS 6.3 or Ubuntu 10 or 12.
This change did not appear to break those already functioning platforms.
Brad King [Tue, 30 Jul 2013 15:37:11 +0000 (11:37 -0400)]
Simplify passing of linker flags to try_compile calls
In commit d7bd02b6 (Modify CHECK_C_SOURCE_* checks to fix builds using
Visual Studio 12, 2013-02-01), commit e3d14342 (Set use of /SAFESEH linker
flag for all LIBARCHIVE_CHECK_C_SOURCE_* checks, 2013-02-01), and commit 58dc42aa (Fix checks for crypto algorithms in Visual Studio builds,
2013-02-01) we introduced and used custom copies of the CMake
CheckCSource(Compiles|Runs) modules in order to pass linker flags to
try_compile calls. CMake has an issue tracker entry about passing
CMAKE_*_LINKER_FLAGS to try_compile calls:
http://www.cmake.org/Bug/view.php?id=14066
Discussion there suggests a much simpler workaround: pass the flags
through the LDFLAGS environment variable. Remove our custom check
macros and use the simpler workaround instead.
Konrad Kleine [Wed, 10 Jul 2013 15:40:55 +0000 (17:40 +0200)]
Run code coverage on your local machine
This change introduces a new make target called "coverage" it will
compile your code using special GCC flags, run the tests, and then
generate a nice HTML output.
This new make target will only be available if you build using GCC in
Debug mode.
To build the code coverage and open it in your browser do this:
mkdir debug
cd debug
cmake -DCMAKE_BUILD_TYPE=Debug -DENABLE_COVERAGE=ON ..
make -j20
make coverage
xdg-open coverage/index.html
Pavel Raiskup [Thu, 27 Jun 2013 14:01:30 +0000 (16:01 +0200)]
Use ustar format in the test_option_b test
.. because the ustar archive does not store SELinux context. As the default
format for bsdtar is "restricted pax" (trying to store xattrs and other
things by default), the test failed on Fedora because our files have by
default SELinux context set. This results in additional data in tested
archive ~> and the test failed because the archive was unexpectedly big:
tar/test/test_option_b.c:41: File archive1.tar has size 3072, expected 2048
Reviewed by Konrad Kleine <konrad.wilhelm.kleine@gmail.com>
Tim Kientzle [Thu, 11 Apr 2013 04:52:15 +0000 (21:52 -0700)]
Issue 314: A tar archive containing only a single 'g' record
should be treated as a valid empty tar archive.
(Such archives are generated by 'git archive' from an empty
repository.)
Tim Kientzle [Sat, 23 Mar 2013 06:48:41 +0000 (23:48 -0700)]
Limit write requests to at most INT_MAX.
This prevents a certain common programming error (passing -1 to write)
from leading to other problems deeper in the library.
Xi Wang [Sun, 20 Jan 2013 23:17:20 +0000 (18:17 -0500)]
Fix overflow checking in archive_entry_sparse_add_entry()
gcc will optimize the overflow check x + y < 0 (assuming x, y >= 0)
into false, since signed integer overflow is undefined behavior in C.
Use a safe precondition check instead.
Andres Mejia [Sun, 24 Feb 2013 18:06:28 +0000 (13:06 -0500)]
Fix test_archive_write_add_filter_by_name_lrzip test case.
There's some bug in lrzip where small files cannot use 2nd stage
compression.
See http://ck-hack.blogspot.com/2012/03/lrzip-0612.html?showComment=1337356929450#c3154145708572533571
Andres Mejia [Sun, 24 Feb 2013 16:54:26 +0000 (11:54 -0500)]
Fix test cases for LZO write support.
Some architectures would produce a bigger archive for compression
level 9 than with the default level, possibly due to memory
limitations.
Fixes #303