dylex / zip-stream Goto Github PK

Hi,

Thanks for providing this great library! With the help of a kind soul on reddit, I've been able to perform a basic stream unzip on a local file and over http. Unfortunately, all stream unzips appear to leak memory; the aforementioned person on reddit is thinking that the leak is related to the file sizes in the zips. As my files are quite large, the leak is also large. More details here: https://www.reddit.com/r/haskellquestions/comments/9nyp15/using_zipstream_to_unzip_an_archive_through/

Any help is appreciated!

Also, along with this, to help other conduit-uninitiated users, it would be helpful to include simple examples of using this library. The code in that same reddit thread could be copy and pasted somewhere in this library.

Hey, thank you for creating this library!

I am using this library to create an archive with an executable file in it, however one can not run it directly after unpacking since it doesn't have an executable bit set. Using zip-archive, I can set the executable bit using externalFileAttributes field. I managed to make it work for compressing with this patch: external-file-attrs.patch, however it wasn't straighforward to do the same for unpacking & cmd.

Thanks again.

I am not sure if this a valid or useful feature, but consider adding a function that will compute zip size for a set of entries, when level zero compression is used. Feel free to close if you don't see it as part of this library.

I'd like to compress ZIP files without compression, since I need to provide the format, but the ZIP comprssion algorithm even on lowest level 1 only does ~25 MB/s on modern CPUs, and uncompressed is incredibly much faster.

The docs say:

It does not (ironically) support uncompressed zip files that have been created as streams, where file sizes are not known beforehand.

I don't quite understand what exactly that means; when zipping with this library, the file sizes are known to it beforehand, aren't they?

See also potentially related (?) #4.

I think it would make sense to have this issue to track this feature of the library being able to decompress its own files.