Harmless typo in a comment.

Merge branch 'master' into fix-mingw

Merge pull request #57 from NiLuJe/fix-has_encrypted_entries

Make sure has_encrypted_entries is a signed int

Merge pull request #54 from NiLuJe/fix-autotools-build

Fix autotools build.

Merge pull request #53 from NiLuJe/fix-issue-317

Fix issue 317

Missed two tests!

(Mentioned in #58, thanks!)

Make sure has_encrypted_entries is a signed int

Related to cd1740912b18f748a4f9b491a32b44c1712a7478

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).

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.

Fix previous commit.

Forgot to check if cpio_windows.h actually pulled windows.h in ;p.

Fix cpio build on MinGW.

Exact same concept as the previous commit.

Better fix.

Restore e6d1e13b2880ab0e6166e5ed168df7e6e0de943b,
and make sure that we include windows.h earlier for the CLI tools.

Revert "Remove unnecessary windows.h include"

This reverts commit e6d1e13b2880ab0e6166e5ed168df7e6e0de943b.

We do need this (for the CLI tools).

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 *);
                                                                ^

Fix issue 317

This is the exact same fix as mentionne din the GC issue,
cf. https://code.google.com/p/libarchive/issues/detail?id=317

Fix autotools build.

Follows commits 4e002d9a92ecd7cec0fb98b0bedbace8aad81f6e &
7a90710e0d3c786cf4f3af2457a815db6c9b5a5a that only handled CMake.

Style:  Use 'int' not 'char' for status return types.
Fix a const mistake.

Style:  Don't check for entry being non-NULL (none
of the archive_entry routines do this); adjust
some indentation to match the other code.

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).

Merge branch 'encryption_detection' of github.com:kwk/libarchive into kwk-encryption_detection

Conflicts:
libarchive/archive_read_support_format_zip.c

Ignore emacs backup files

Refactor archive_version_details to eliminate size and printf concerns

Merge branch 'archive-version-details' of github.com:rosslagerwall/libarchive into rosslagerwall-archive-version-details

Merge branch 'local_coverage' of github.com:kwk/libarchive into kwk-local_coverage

Conflicts:
CMakeLists.txt

Refactor lafe_setprogname slightly to avoid the repeated logic about default handling

Merge branch 'master' of github.com:jymigeon/libarchive into jymigeon-master

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.

Moved local code coverage code separate script

Merge pull request #50 from mcuelenaere/fix-win32-ascii-unicode

Use correct variable types for ASCII Windows functions.

Merge pull request #52 from seishun/patch-1

Remove unnecessary windows.h include

Merge pull request #48 from kwk/master

Added all Zip compression names from 6.3.3 format

Merge pull request #46 from trel/master

include linux/types.h on CentOS 5 in test/test_sparse_basic.c

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).

Fix tar test build with CMake

Merge pull request #39 from arsenm/master

Fix test builds when building as a sub-project

Merge branch 'master' of github.com:libarchive/libarchive

tar option mac-ext can now be used to control whether mac extensions are processed; defaults to off on non-MacOS

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.

Fix tabs.

Issue 320:  Rewrite (again) to avoid the left shift that CLang dislikes so much.

This version simulates 2s-complement arithmetic on an
unsigned value, then casts it to signed at the end.

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.

Merge branch 'master' of github.com:libarchive/libarchive

Add tests to verify that the seeking Zip reader can correctly
ignore padding at beginning or end.  Fix Issue #257.

Export the seekable and streamable zip readers separately
to simplify testing.

Mention the -r option when we can't find our reference files.

Remove unnecessary windows.h include

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.

Avoid struct init with variable

Compilers such as Borland and MIPSpro do not like struct initialization
with variables.  Initialize using assignment instead.

Merge branch 'simplify-link-flags'

Merge branch 'no-signed-shift'

Store encryption info in single char of entry

Instead of two chars the information about encryption is now stored in
one single char inside of an archive_entry struct.

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:
-------------------------------------------

With header encrpytion (-mhe=on):

    $ rm -f test_read_format_7zip_encryption_header.7z
    $ echo "foo" > bar.txt && 7z a -mhe=on -p12345678 \
    test_read_format_7zip_encryption_header.7z bar.txt

    $ uuencode test_read_format_7zip_encryption_header.7z \
    test_read_format_7zip_encryption_header.7z > \
    test_read_format_7zip_encryption_header.7z.uu

Without header encrpytion (-mhe=off):

    $ rm -f test_read_format_7zip_encryption.7z
    $ echo "foo" > bar.txt && 7z a -mhe=off -p12345678 \
    test_read_format_7zip_encryption.7z bar.txt

    $ uuencode test_read_format_7zip_encryption.7z \
    test_read_format_7zip_encryption.7z > \
    test_read_format_7zip_encryption.7z.uu

Partially encrypted archive:

$ rm -f test_read_format_7zip_encryption_partially.7z
$ echo "foo" > bar_unencrypted.txt && 7z a \
test_read_format_7zip_encryption_partially.7z bar_unencrypted.txt
$ echo "foo" > bar_encrypted.txt && 7z a -mhe=off -p12345678 \
test_read_format_7zip_encryption_partially.7z bar_encrypted.txt

$ uuencode test_read_format_7zip_encryption_partially.7z \
test_read_format_7zip_encryption_partially.7z > \
test_read_format_7zip_encryption_partially.7z.uu

Here's how I generated the RAR test files:
------------------------------------------

These are the files we can will add to the archives:

    echo "data of foo.txt" > foo.txt
    echo "data of bar.txt" > bar.txt

 With header encrpytion (-hp):

    rm -f test_read_format_rar_encryption_header.rar
    rar a -hp12345678 test_read_format_rar_encryption_header.rar \
    foo.txt bar.txt

    uuencode test_read_format_rar_encryption_header.rar \
    test_read_format_rar_encryption_header.rar > \
    test_read_format_rar_encryption_header.rar.uu

Without header encrpytion (-p):

    rm -f test_read_format_rar_encryption_data.rar
    rar a -p12345678 test_read_format_rar_encryption_data.rar \
    foo.txt bar.txt

    uuencode test_read_format_rar_encryption_data.rar \
    test_read_format_rar_encryption_data.rar > \
    test_read_format_rar_encryption_data.rar.uu

Partially encrypted archive (-p on "foo.txt" and no password on "bar.txt"):

    rm -f test_read_format_rar_encryption_partially.rar
    rar a -p12345678 test_read_format_rar_encryption_partially.rar foo.txt
    rar a test_read_format_rar_encryption_partially.rar bar.txt

    uuencode test_read_format_rar_encryption_partially.rar \
    test_read_format_rar_encryption_partially.rar > \
    test_read_format_rar_encryption_partially.rar.uu

Here's how I generated the ZIP test files:
------------------------------------------

This is how I've created the test files:

These are the files we will add to the archives:
  On Windows:
    echo "data of foo.txt" > foo.txt
    echo "data of bar.txt" > bar.txt

For the creation of the Zip archives I've used the
PKZIP Command Line Add-On available from here:

http://comm.pkware.com/pkzip-cli-download.html

With header (aka central directory) encrpytion (-cd):

  On Windows:
    del /F test_read_format_zip_encryption_header.zip
    pkzipc.exe -add -cryptalgorithm=AES,256 -passphrase=12345678 -cd test_read_format_zip_encryption_header.zip foo.txt bar.txt

  On Linux:
    uuencode test_read_format_zip_encryption_header.zip \
    test_read_format_zip_encryption_header.zip > \
    test_read_format_zip_encryption_header.zip.uu

Without header encrpytion:

  On Windows:
    del /F test_read_format_zip_encryption_data.zip
    pkzipc.exe -add -cryptalgorithm=AES,256 -passphrase=12345678 test_read_format_zip_encryption_data.zip foo.txt bar.txt

  On Linux:
    uuencode test_read_format_zip_encryption_data.zip \
    test_read_format_zip_encryption_data.zip > \
    test_read_format_zip_encryption_data.zip.uu

Partially encrypted archive ("foo.txt" is encrypted and "bar.txt" is not):

  On Windows:
    del /F test_read_format_zip_encryption_partially.zip
    pkzipc.exe -add -cryptalgorithm=AES,256 -passphrase=12345678 test_read_format_zip_encryption_partially.zip foo.txt
    pkzipc.exe -add test_read_format_zip_encryption_partially.zip bar.txt

  On Linux:
    uuencode test_read_format_zip_encryption_partially.zip \
    test_read_format_zip_encryption_partially.zip > \
    test_read_format_zip_encryption_partially.zip.uu

Use correct variable types for ASCII Windows functions.

There are both an ASCII and an Unicode variant for most of the Win32 API.
Fix some inconsistent uses.

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.

http://code.google.com/p/libarchive/issues/detail?id=118

Removed compression_method struct type

Since it was only used in one place, I've remove the struct type.

Simplified and fixed Zip compression method array

I've removed the description string element from the compression_method
struct and fixed some spelling errors (imb -> ibm).

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:

http://www.pkware.com/documents/casestudies/APPNOTE.TXT

Hide *lafe_progname and provide getter/setter instead.

This factorizes some code between binaries like bsdtar, bsdcpio, and
the soon-to-be mtree.

st_dev field corresponds to dev{major,minor} and not rdev{major,minor}.

Bug fix (segfault): check filename against NULL in case we want
the output to go to stdout.

Document "resdevice" and "inode".

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.

Small typo fix in parse_device()'s description.

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.

Fix chown line in shardump format

Currently the chown line is written with no space before entry name.

Some more test cases around the "2 hours ago" concept.

Merge branch 'master' of github.com:libarchive/libarchive

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.

Document the "device" keyword and its value.

Typo fix.

"optional" is also supported, so add it to mtree.5.

sha384 and sha512 are supported tags, add them to mtree.5.

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.

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.

http://code.google.com/p/libarchive/issues/detail?id=325

Close the file handle on error.

http://code.google.com/p/libarchive/issues/detail?id=325

Simplify the method/level checks here and fix a bug.

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

Add more files autogenerated by automake build system to .gitignore.

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>

Rework the sign-extension to avoid left-shift of
an explicit negative number (which newer GCC complains about).

Updated libarchive.spec from Nikolai Lifanov.

Merge pull request #32 from bamiaux/fix_win32_exclusive_read_access

Do not require exclusive read access when reading files under windows

Merge pull request #40 from juikim/master

Do not overwrite file size if the local file header has valid file size.

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.)

http://thread.gmane.org/gmane.comp.version-control.git/220485
http://code.google.com/p/libarchive/issues/detail?id=314

Expose the generic archive_free hook

If seek fails, fail the xar read.  We should be able to do better than this.

Do not overwrite file size if the local file header has valid file size.
This allows us to extract index.xml from Apple iWork '09 format files.

Merge pull request #33 from xiw/overflow

Fix overflow checking in archive_entry_sparse_add_entry()

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.

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.

Fix cmake test builds when building as a sub-project

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

Allow the option to use no 2nd stage compression with lrzip.

Initialize buff to all zeros.

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

write_raw support from Marek Kubica

Merged branch 'feature/write-format-raw' of https://github.com/Leonidas-from-XIV/libarchive

Revert "Allow adding extra CFLAGS with a configure option."

This reverts commit 64b3cefbdbc0d6deef1dd3bcde890e273c323168.

Apparently, setting CFLAGS won't override the preset AM_CFLAGS
afterall. Not sure why this was giving me a problem before.

Revert "Remove unnecessary use of arguments from AC_ARG_WITH([extra-cflags])."

This reverts commit 6a917dcd1378e2a50ece9f007e79a8a5058a59cb.

Remove unnecessary use of arguments from AC_ARG_WITH([extra-cflags]).

Allow adding extra CFLAGS with a configure option.
This is a convenience option to pass in extra CFLAGS without overriding other
CFLAGS.

Fix compile warning due to -Wcast-qual.

Fix compiler warning from compiling with clang.
Assigning from a read-only variable to a regular variable will issue
a warning from clang.