Do not redefine _WIN32_WINNT and WINVER

Make the backslash line continuations more consistent for automatic updating; update the libarchive test data

Fix the zip tests that were inadvertently disabled (and hence broken).

Extend them to verify with/without forcing zip64 and with/without 'el' extension.

Include missing test in cmake build, sort the file list.

Include tests for new zip64 functionality in autoconf-based build.

Fix out-of-tree build

When building outside the source tree, the directories 'libarchive/test',
'tar/test' and 'cpio/test' need to be created before the commands in Makefile.am
are executed which create list.h files in these directories.

Signed-off-by: Paul Barker <paul@paulbarker.me.uk>

Merge pull request #62 from kientzle/master

Zip64 refactoring

Do not require LibXml2 to configure

In commit 033fc31e (Allow fine grained control over dependancies,
2013-05-16, committed 2013-12-12) the find_package(LibXml2) line was
accidentally given a REQUIRED specifier.  Remove it now.

Merge pull request #59 from NiLuJe/fix-warning

Fix a minor sign issue.

Add a test for read_concatenated_archives

Make sure that we are reading the concatenated contents when requested
and only when requested.

Signed-off-by: Kevin Locke <kevin@kevinlocke.name>

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

Verify that Zip writer rejects too-large files when Zip64 is disabled.

Interestingly, this found a bug in the write core:  if the
writer rejects a file, the write core would erroneously transition to
state DATA.

Verify the end-of-archive information as part of the large zip test.

Fix a bug that breaks compat with Info-Zip 'unzip' program.

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

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>

Only enable the still-experimental 'el' extra block
if option 'zip:experimental' is specified.
This should limit the use of this option until the
final format is actually nailed down.

Issue #329: https://code.google.com/p/libarchive/issues/detail?id=329

Fix POSIX.1e draft ACL handling on Linux systems that lack NFSv4 ACL libraries.

Fix a minor sign issue.

archive_read_support_format_tar.c:802:16: error: comparison between
signed and unsigned integer expressions [-Werror=sign-compare]

Change new extra block from 'LA' to 'el' to follow updated draft spec

Add a bitmap to indicate which fields are included for compression and for future expansion

Change the first field of the 'LA' extra block to the full 'version made by'

Improve memory management in the large zip test

Only write the new 'LA' experimental extra block if it's explicitly enabled.
Enable it in the appropriate tests.

E.g.,

$ bsdtar cf - --format=zip --option zip:experimental .

The syntax supports multiple experiments;
use --option zip:experiment_la to enable just the 'LA' experiment.

A couple of changes to the experimental new extra block, as suggested by Steven Schweda.

 * Name changed from 'at' to 'LA' (Local Attributes)
 * Trimmed 'version made by' down to just 1 byte system code

Be stricter about the checksum field; reduce false-positives on the bid

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.

Move a 1MB buffer off the stack and onto the heap.

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