Release: 2.1.0.100 (Canary) 2024-11-25

[ts678]

@kenkendk

It was removed because it was unstable and has been giving a warning for at least 7 years

That comment refers to 7z (I think). I’m thinking that issue here refers to this. 2.0.9.111 claims:

  --zip-compression-method (Enumeration): Set the ZIP compression method
    Use this option to set an alternative compressor method, such as LZMA. Note that using another value than Deflate will cause the option --zip-compression-level to be ignored.
    * values: None, Deflate, BZip2, LZMA, PPMd, GZip, Xz, Deflate64
    * default value: Deflate

but also new:

  --zip-compression-library (Enumeration): Toggles the zip library to use
    This option changes the compression library used to read and write files. The SharpCompress library has more features and is more resilient where the built-in library is faster. When Auto is chosen, the
    built-in library will be used unless an option is added that requires SharpCompress.
    * values: Auto, SharpCompress, BuiltIn
    * default value: Auto

@kenkendk

The built-in .Net zip is much faster than SharpCompress, but only supports Deflate+Store algorithms. In case any one else experiences this, the solution is to request SharpCompress:

--zip-compression-library=SharpCompress

For most cases, there will be an automatic fallback to SharpCompress, but in this case the fallback mechanism is not triggered as .NET was able to open and read the headers without problems.

EDIT 1:

I tested this. For direct restore, the option shown above put into screen 2 makes it work for me.

EDIT 2:

How many other zip-compression-method are going to fall into this? People do choose others.