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
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.
This change adds a FileOptions struct. This struct can be filled using a builder pattern
to set the options for a file or folder.
With this change, we also introduce the option to set the (unix) permissions of a file or folder.
