ZIP does not use a proper timestamp but uses something called "DOS time".
This is a weird old format with some limitations like accuracy of only
2 seconds, but also no timezone information.
Also unline UNIX time it is not relative to some specific point in time
with timezone information, but is always considered to be the local
time. Meaning we need to convert it first to the users local time.
Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
Directories should also have the correct mtime set and not the current
time. For this the `Streamer` class needs to support passing a time
attribute for creating folders, the underlying library already supports
this.
Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
Else we might run into the issue that for an external storage where the
size is not known yet we do not use zip64. Which then of course fails on
large zip files.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
To continue this formatting madness, here's a tiny patch that adds
unified formatting for control structures like if and loops as well as
classes, their methods and anonymous functions. This basically forces
the constructs to start on the same line. This is not exactly what PSR2
wants, but I think we can have a few exceptions with "our" style. The
starting of braces on the same line is pracrically standard for our
code.
This also removes and empty lines from method/function bodies at the
beginning and end.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
* avoids a 403, but enables download of resources that are not restricted
* single file downloads still cause 403
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
A zip32 file can contain, at most, 65535 files (and folders), so take
that constraint into account.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
* OSX doesn't handle 64zip that well
* Some other implentations don't handle it perfectly either
* If the file is belog 4GiB (some overhead) => zip32
* This covers the 99% case I bet
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>