Closed onnokort closed 3 years ago
Hi, I think the current way parsing arguments is the common way of doing things. The correct command should be:
$ lrzip -zUL 9 MY_FILE
Hope this help, please close the issue if it does.
Thanks! My issue is rather that lrzip is silently ignoring command line options, not that there is a common way to do things. (And I am not complaining that my way of trying to call it isn't the common way or not accepted!)
I just think that if something is an invalid combination of arguments, lrzip should fail, or warn loudly. (Of course, if there's an easy way to accept my variant as well, that would solve it, too)
If you use lrzip the wrong way, as I described above, and have it part of a chain of commands in e.g. a shell script, you might wonder why it is so fast (though expected to use ZPAQ) and why the resulting file isn't smaller than just using LZMA.
That is what bit me. If lrzip would have been more strict about its command line parsing, I would have caught the problem in my case earlier.
Does that make sense?
Thank you. I understand what you mean now, indeed the argument parser silently ignore the parameter -U and -z in your example (I suggest changing the title to lrzip silently ignore arguments after parse error
to make this more clear):
alexvong1995@debian:~$ lrzip -vvL9Uz signature.asc
The following options are in effect for this COMPRESSION.
Threading is ENABLED. Number of CPUs detected: 2
Detected 4030414848 bytes ram
Compression level 9
Nice Value: 19
Show Progress
Max Verbose
Temporary Directory set as: ./
Compression mode is: LZMA. LZO Compressibility testing enabled
Heuristically Computed Compression Window: 25 = 2500MB
Storage time in seconds 1472087645
Output filename is: signature.asc.lrz
File size: 1702
Succeeded in testing 1702 sized mmap for rzip pre-processing
Will take 1 pass
Chunk size: 1702
Byte width: 2
Succeeded in testing 775950336 sized malloc for back end compression
Using only 1 thread to compress up to 4096 bytes
Beginning rzip pre-processing phase
hashsize = 4194304. bits = 22. 64MB
819 total hashes -- 808 in primary bucket (98.657%)
Malloced 1343471616 for checksum ckbuf
Starting thread 0 to compress 10 bytes from stream 0
Writing initial chunk bytes value 2 at 24
Writing EOF flag as 1
Writing initial header at 28
Compthread 0 seeking to 5 to store length 2
Compthread 0 seeking to 14 to write header
Thread 0 writing 10 compressed bytes from stream 0
Compthread 0 writing data at 21
Starting thread 0 to compress 1702 bytes from stream 1
lzo testing FAILED for chunk 1702. Compressed size = 100.47% of chunk, 1 Passes
Compthread 0 seeking to 12 to store length 2
Compthread 0 seeking to 31 to write header
Thread 0 writing 1702 compressed bytes from stream 1
Compthread 0 writing data at 38
MD5: 097571ee810a7c0d488e3d5763b2da2d
matches=0 match_bytes=0
literals=2 literal_bytes=1702
true_tag_positives=0 false_tag_positives=21
inserts=822 match 0.001
signature.asc - Compression Ratio: 0.954. Average Compression Speed: 0.000MB/s.
Total time: 00:00:00.25
Notice
Compression level 9
,
Heuristically Computed Compression Window: 25 = 2500MB
and
Compression mode is: LZMA. LZO Compressibility testing enabled
. Maybe we should compare how lrzip and other achievers handle argument parsing and see what we can do here.
Fixed in master.
IMO lrzip should either parse the following command line correctly or flag an error:
$ lrzip -L9Uz
This will not complain and zip the file, but won't, as far as I can see, apply zpaq compression.
The following works fine:
$ lrzip -L 9 -U -z
Version: 0.616
Last but not least: Thanks for this otherwise absolutely great tool!