nils måsén
nils måsén
I am currently working on replacing the BZip-code (https://github.com/piksel/SharpZipLib/tree/jbzip2) and using that branch it compresses your blob in about 12s on the same machine. It actually passes the tests, but...
Yes, the blockSize was just a red herring. I just wanted a working sample to use as a comparison when debugging the code.
Yeah, it should just be a matter of throwing the same exception as in https://github.com/icsharpcode/SharpZipLib/pull/420
The example is using ZipFile from a ZipFile stream recursevly. This cannot be done from a ZipInputStream, since, like the error message says, it does not support seeking.
Sorry, I misread your initial issue. The stream returned from `ZipFile.GetInputStream` is only seekable if it's not compressed. I'm not sure why there is an example that explicitly does this....
@Numpsy Sure! I am restructuring the wiki examples now. You can just add it as a new page and link it from [Zip-Samples](https://github.com/icsharpcode/SharpZipLib/wiki/Zip-Samples)
@Numpsy I added a slightly modified version of your example here: [Zip-Samples > Create a Zip from a HTML string](https://github.com/icsharpcode/SharpZipLib/wiki/Zip-Samples#create-a-zip-from-a-html-string-c)
1. Yeah, I think that's ideal 2. I would presume that setting it when committing the updates is less error-prone. Do you see any down sides to it?
No, I guess that would be fine.
They should probably be their own issues, although much of the work done in #574 can be used to implement them in the other streams as well. `full async/await pattern...