aonez / Keka

The macOS & iOS file archiver
https://www.keka.io
4.77k stars 236 forks source link

Let's discuss LRZIP and what Keka should do with it #797

Open MaxPower85 opened 3 years ago

MaxPower85 commented 3 years ago

First, I think the LRZIP tab needs to mention which version of LRZIP is used and to maybe have like some "tooltip" message when you hover the mouse pointer over it about the compatibility of different versions... something that briefly summarizes the readme file about the compatibility, that archives made with a newer version may not be fully compatible with older versions http://ck.kolivas.org/apps/lrzip/lrzip-0.640/README-NOT-BACKWARD-COMPATIBLE

People should be aware of it if the format changes in the future.

Maybe Keka should concatenate a small txt file to the archive that says something like "Keka LRZIP 0.6x LZMA LVL 8" or "Keka LRZIP 0.6x ZPAQ", so someone could find out which version and settings were used for future reference... and maybe that could be mentioned in the "tooltip" about the version number (something like "You can look at the ending of a file with a HEX editor to see which version and settings were used").

BTW... don't forget to mention which version of LRZIP is used in Keka's "About" window too... and maybe also mention that Keka supports LRZIP on MacUpdate and in other places as one of the main features... so if people need an archiver that supports LRZIP, to find Keka more easily.

Also... I think it would be good if someone could maybe contact some developer who developers Windows software and is interested in archivers, to add support to some archiver that works on Windows for LRZIP or to at least make some pre-compiled binary that Windows users who haven't tried compiling anything before could just download and use... I think that is really important for the adoption of LRZIP... so people would know that if they use it and send it to someone who's on Windows, that it wouldn't be too much of a hassle for them to uncompress it on Windows.

About the options... since LRZIP can use different compression formats and encryption, I think LRZIP's tab should show options for it... and people also need to know that it's not just one format... that it takes significantly longer to decompress it when ZPAQ is used than when they select BZIP2 for LRZIP.

http://manpagez.com/man/1/lrzip/

For example, add a drop down box for someone to choose LZMA (default when ZPAQ isn't used), BZIP2, GZIP... when those are selected, the LVL selector should be enabled...

The LVL selector should be disabled when someone selects LZO, ZPAQ or "Prepare for another compressor" (for "-n", which does not compress, but it seems to deduplicate stuff and make it easy for another compressor to later compress it).

BTW... since the progress bar doesn't seem accurate for LRZIP... can you show the progress text that the original LRZIP binary shows in the Terminal when it's used, as it looks it the terminal instead of the progress bar... and for the text when you click on the "!" to look more like how it does in the Terminal instead of looking like it's all over the place...

So, not like this:

Total: 1% Chunk: 1% Total: 2% Chunk: 2% Total: 3% Chunk: 3% Total: 4% Chunk: 4% Total: 5% Chunk: 5% Total: 6% Chunk: 6% Total: 7% Chunk: 7% Total: 8% Chunk: 8% Total: 9% Chunk: 9% Chunk: 49% Chunk: 69%

      ZPAQ    1:0%  

      ZPAQ        2:0%  

      ZPAQ            3:0%  

      ZPAQ                4:0%  

      ZPAQ                    5:0%  

Chunk: 468% Chunk: 473% Chunk: 479% Chunk: 495% Chunk: 500% Chunk: 506% Chunk: 519% Chunk: 525% Chunk: 534% Chunk: 544%

      ZPAQ                        6:0%  
aonez commented 3 years ago

BTW... don't forget to mention which version of LRZIP is used in Keka's "About" window too...

Forgot it! This will come in next release. Also LRZIP just has been updated to 0.640 so will be updated too. Was using the latest version 0.631.

aonez commented 3 years ago

First, I think the LRZIP tab needs to mention which version of LRZIP is used and to maybe have like some "tooltip" message when you hover the mouse pointer over it about the compatibility of different versions... something that briefly summarizes the readme file about the compatibility, that archives made with a newer version may not be fully compatible with older versions http://ck.kolivas.org/apps/lrzip/lrzip-0.640/README-NOT-BACKWARD-COMPATIBLE

Fair enough. Since Keka started with 0.6 not sure if makes sense right now but in the event of a 0.7 not compatible with 0.6 sure it will be needed a disclaimer.

Also... I think it would be good if someone could maybe contact some developer who developers Windows software and is interested in archivers, to add support to some archiver that works on Windows for LRZIP or to at least make some pre-compiled binary that Windows users who haven't tried compiling anything before could just download and use... I think that is really important for the adoption of LRZIP... so people would know that if they use it and send it to someone who's on Windows, that it wouldn't be too much of a hassle for them to uncompress it on Windows.

Maybe Igor from 7-Zip? Maybe you can ask him in the SorceForge forum.

BTW... since the progress bar doesn't seem accurate for LRZIP... can you show the progress text that the original LRZIP binary shows in the Terminal when it's used, as it looks it the terminal instead of the progress bar... and for the text when you click on the "!" to look more like how it does in the Terminal instead of looking like it's all over the place...

It's hard to track the progress of this binary 😂 will try to enhance it

pete4abw commented 3 years ago

Wrapping lrzip or lrzip-next is challenging. It is and has always been meant to be a command line tool. Reporting progress with multiple threads running simultaneously is hard. With ZPAQ APi being updated to 7.15, the ZPAQ compression progress is no longer available on compression due to the use of streams. Recent changes in lrzip-next have corrected some MacOS compile issues See libzpaq detects macOS as Windows. Good luck

giovariot commented 4 months ago

I think a good idea would be to implement some kind of command to use the -U option (unlimited range data deduplication) which is in my opinion the most important reason to use lrzip over other compression algorithms.

I use lrzip to compress disk backups and the -U option is a life saver allowing for even greater compression ratios.