Instead of using string directly, also accept a Path object. This moves
the responsibility from using the correct path separator and not using
invalid path components to this library.
The naming matches that of std::fs::Metadata.
An entry is determined to be a directory based on the presence of
a trailing path separator, i.e. '/' or '\'.
This patch adds a small test zip containing files and directories.
Their names match their type so as to make testing easy.
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).
If a directory name does not end with a slash, append it to it when
writing a zip file. This way we can ensure it is distuinguishable from
an empty file.
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.
Zip files can contain both / and \ as separators regardless of the OS and as we want to return a sanitized PathBuf that only supports the OS separator on the let's convert incompatible separators to compatible ones.
If one doesn't do this then PathBufs will be returned that can have entire paths in the file name such as "src\\lib.rs" on Linux/Mac, instead of srv / lib.rs as 3 separate components.
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
