The `?` operator exists since Rust version 1.13.0 and has since become the
standard and recommended variant over the `try!` macro (see
https://doc.rust-lang.org/std/macro.try.html where it is explicitly mentioned to
use the `?` operator instead of the `try!` macro).
I think it is especially useful to replace the `try!` usages throughout the
examples (since new users might not be familiar with the `try!` macro at all).
Offset to the start of central directory may be 0xFFFFFFFF if it is a
Zip64 file. Previously, that value was used when calculating the archive
offset. The value will now be ignored if the Zip64 central directory
could be located.
You can now repeatedly call a function to iterate over all files in a
zip. This may give some suboptimal results, but is useful when dealing
with an incoming data stream.
Do not pre-allocate the number of files, as this might be an invalid
number.
Also give a more helpfull error message when the start of the central
directory could not be found.
Resolves#68
The msdos datetime 0x00000000 is invalid. The Windows API would
(rightfully) return an ERROR_INVALID_PARAMETER for this when converting
it. If it is indeed an invalid error, we now return the zip datetime
'epoch' of 1980-01-01 00:00:00.
Resolves issue #61
I constructed this file using a hack from the Zip manpage: if the input to a
Zip compression command is streamed on standard input, the output is given in
ZIP64 format since the tool doesn't know how big the input will be. I modified
the resulting file by adding some leading junk text and editing the non-ZIP64
end-of-central-directory structure to have 0xFFFF for its "number of files"
parameters, to help the test demonstrate that the ZIP64 data are being
properly read. (0xFFFF is the value used in the non-ZIP64 structure if the
archive actually has more than 65535 files.)
This provides only very basic ZIP64 support, but it allows us to properly read
archives with more than 65535 files, so long as none of the individual files
need ZIP64 support to be read.
The newely added read_exact from std::..::Read has an incompatible signature
and is not yet stabilized. This ensures that the crate will work on stable and
nightly.
