Support experimental "at" extra block for better streaming.

The writer now writes this extra block with every local
file header; the reader recognizes it and uses it.
This allows streaming extraction to properly restore
file permissions and symlinks.

Without this, streaming extraction of Zip archives is
somewhat hobbled by the lack of full information in
the local file header.

Here's a detailed description of the new extra block.
The details here are subject to change at any time.

   -Extended Local File Header Extra Field (0x7461):

      The following is the layout of the extended local file
      header "extra" block.  This allows information to be
      included with the local file header that could previously
      only be stored with the central directory file header.

      Note: all fields stored in Intel low-byte/high-byte order.

        Value      Size       Description
        -----      ----       -----------
        0x7461     2 bytes    Tag for this "extra" block type
        Size       2 bytes    Size of this "extra" block
        Version
        Made By    2 bytes    See "Version Made By" above
        Internal File
        Attributes 2 bytes    See "Internal File Attributes" above
        External File
        Attributes 4 bytes    See "External File Attributes" above

      This extra block should only be used with the local
      file header.  The values stored should exactly match
      the corresponding values in the central directory
      file header.

Comment the definitive Zip documentation for future maintainers; note the history of this code.

Convert some booleans into more compact bitfields

More code rearranging

Update some comments, fine-tune the streaming bid

Remove some redundant vars; more code reorg

Optimize skipping entries in seeking mode

Clarify the wording.

Eliminate zip reader's redundant tracking of file position (the archive already does this).

Make zip->offset tracking more consistent.

Fix large zip test in streaming mode.

Return uncompressed size if it's known, even if compressed size and/or CRC are deferred.

Skip stored data quickly when size is known at beginning even when CRC is at end

Update some comments

Extend large zip test to cover streaming reader as well.

Expand the large zip test a bit

Parse out the extra data before trying to insert into the tree.

Since the tree is organized by offset, we
need the full offset from the extra data
(in the case of 64-bit offsets) before we do the
insertion.

While here, fix an obvious blooper: initialize the CRC function.

Test for large Zip archives, following code for large Tar test.
Fix several bugs:
 * comparison function for ordering entries in reader was wrong
 * writer wasn't including 64-bit sizes for entries of exactly 0xffffffff bytes
Also, add options to suppress CRC calculations and checks
(otherwise, this test spends a *lot* of time in CRC routines).

Read Zip64 EOCD; work around an Info-Zip bug.

Fix whitespace

Finish the detailed verification of zip archive with single entry for both zip64 and non-zip64 cases.
Fix a few minor issues this uncovers.

Test detailed zip format for regular file entry.
Fix tests when built w/o zlib.

Don't try to verify deflated data if zlib is unavailable.

Rename write/read round-trip test.

Comment this test a little bit.

Test that we can read the Zip64 extensions that we write.

Be more careful about enabling zip64 (fixes zip_compression_store test)
Add test for empty zip64 file
Fix reader to read empty zip64 files

More error reporting on these assertions.

Adjust expected permissions; zip code has slightly tightened
the default permissions used when extracting files.

Fix all current tests:
 * When searching for start of Central directory, DTRT if there are no entries.
 * Find end-of-archive marker when it is exactly at end of file
 * Recognize zip64 central directory locator (not yet fully parsed)
 * Don't return entry size if length-at-end, even if size looks reasonable

Out-of-range seeks should fail, not truncate the seek.

Set compiler flags for Clang.

Break Zip compatibility test into 5 separate tests.

Fix mismatched sign warning

Fix warnings:  mismatched signs, unused variables.

Merge branch 'master' of github.com:kientzle/libarchive-zip64

Fix typo

Merge recent changes from libarchive master repository.

Cleanups for zip64 support

Move the strsep() implementation to the mtree reader, which is
the only place it's used.

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

Checkpoint work on zip64 support

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.

Remove unused variables

gitignore all emacs backup files

Remove deleted test from makefiles

Remove the redundant test.

Refactor Zip writer.

Zip writer no longer preserves full archive_entry objects for
every entry; it just accumulates the actual bytes to be put
into the central directory.  Most of the central directory file
header is formatted at the same time as the local file header.
The header formatting is refactored to make it easier to support
variable-length extra data.

The tests are adjusted to match the new output:  We include more
detailed extra data in the central directory, we're more selective
about generating data descriptors (they're not needed for directory
entries, for instance), UT extra data now includes only the time
fields specified by the user, we're setting the "version required"
field more accurately.

There are some initial attempts to include Zip64 extensions
when appropriate; that still needs lots of work.  I'm not
yet sure how to test Zip64 support without generating gigantic
archives.  Hmmm...

Support Zip64 extra data fields for handling large entries.

Process extra data fields for central directory and local file headers
so we get correct full size information in both cases.
Correct central directory vs. local file header sanity check
to compare full size information (including data picked out of
the extra data).

Note:  This does not yet support the Zip64 end-of-central-directory
marker so doesn't correctly handle very large archives.

Adjust format for longer test names.

Start refactoring Zip writer:
 * Build list of entries for Central directory at entry_finish
   (So we can switch in-memory Central dir to a list of binary blobs.)
 * Rename some variables to clarify the code.
 * Add 'zip64' option to force zip64 extensions for testing

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.