| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
It is desirable to keep the contents of the generated file below a
directory, ideally named after the ZIP file itself, so that extraction
tools can extract the files to a subdirectory, rather than spilling its
contents to the working directory.
|
| |
|
|
|
|
|
| |
Even if basename(3) does modify the input string [1], the returned
pointer is only used as a reference in this context.
[1]: https://pubs.opengroup.org/onlinepubs/9699919799/functions/basename.html
|
| |
|
|
|
|
|
|
| |
When an empty directory is to be downloaded, z->lread would always equal
zero because read_file is never called.
Therefore, it is more sensible not to assume any number of bytes, and
just dump as much data as possible into buf.
|
| | |
|
| |
|
|
|
|
| |
libweb now supports deallocating user-defined data whenever an error
occurs during a chunked transfer or an asynchronous HTTP response, thus
avoiding memory leaks.
|
|
|
Thanks to the fdzipstream library [1] and zlib [2], it is possible to
generate ZIP files on-the-fly, therefore requiring no extra disk space
usage and only a small amount of memory.
Unfortunately, as of the time of this writing fdzipstream is not
packaged by any distributions yet [3], so it had to be imported as a git
submodule as a workaround.
While libarchive [4] could be an interesting alternative, writing ZIP
files is only supported by very recent versions (>= 3.8.0), which are
still not packaged by many distributions [5], either.
Moreover, libarchive is a package with several dependencies other than
zlib and is significantly larger compared to fdzipstreams, so
fdzipstreams was ultimately considered a better fit for this purpose.
[1]: https://github.com/CTrabant/fdzipstream.git
[2]: http://zlib.net/
[3]: https://repology.org/projects/?search=fdzipstream
[4]: https://www.libarchive.org/
[5]: https://repology.org/project/libarchive/versions
|
