Total Commander

The default is currently 6. The dll accepts values from 1 to 9 without error. I don't know what values it uses when I set it to 6, b ut for consistency with the ZIP packer I prefer to use 6 instead of 5.

2ghisler(Author)
As I do remember -mx6=-mx5 (Normal) and -mx8=-mx9 (Ultra) but I can't check it now.

My test for different -mx switches only. No another parameters added.
7zip version 24.08.
Totalcmd.exe is 11.03 32 bit.

E.g.
7z.exe a -mx=5 "TOTALCMD.EXE 5.7z" "TOTALCMD.EXE"
7z.exe a -mx=2 "TOTALCMD.EXE 2.7z" "TOTALCMD.EXE"
etc...

Results:

TOTALCMD.EXE 1.7z    1 941 857   08.11.2024 20:03   -a--
TOTALCMD.EXE 2.7z    1 885 630   08.11.2024 20:03   -a--
TOTALCMD.EXE 3.7z    1 859 420   08.11.2024 20:03   -a--
TOTALCMD.EXE 4.7z    1 858 037   08.11.2024 20:02   -a--
TOTALCMD.EXE 5.7z    1 707 803   08.11.2024 20:02   -a--
TOTALCMD.EXE 6.7z    1 707 803   08.11.2024 20:02   -a--
TOTALCMD.EXE 7.7z    1 703 818   08.11.2024 20:02   -a--
TOTALCMD.EXE 8.7z    1 683 375   08.11.2024 20:02   -a--
TOTALCMD.EXE 9.7z    1 683 375   08.11.2024 20:01   -a--

5=6
8=9

I did som tests - and found this (all with non-solid archives):

I get identical archives if I pack with TC and set the compression rate to 3 or 4
I get identical archives if I pack with TC and set the compression rate to 5 or 6
I get identical archives if I pack with TC and set the compression rate to 8 or 9

I get identical archives for both internal and external packing with TC if I set compression rate between 1 to 7 (both incluced) - also when packing .exe and .dll files - but not when the archive contains subdirs.

Packing with compression rate 0 makes identical archives if I pack with Internal packer in TC or with 7zFM.exe - BUT I get very different size if I pack from TC with external packer (7zG.exe) - the files are not stored, but compressed.

Packing with compression rate 1 in TC, external or internal, is equivalent to packing with 7zFM.exe with rate 0
Packing with compression rate 2 in TC, external or internal, is NOT equivalent to packing with 7zFM.exe with rate 1
Packing with compression rate 3 or 4 in TC, external or internal, is equivalent to packing with 7zFM.exe with rate 3
Packing with compression rate 5 or 6 in TC, external or internal, is equivalent to packing with 7zFM.exe with rate 5
Packing with compression rate 7 in TC, external or internal, is equivalent to packing with 7zFM.exe with rate 7
Packing with compression rate 8 or 9 in TC, external or internal, is equivalent to packing with 7zFM.exe with rate 9 if .exe and .dll files are NOT involved
Packing with compression rate 8 or 9 in TC, internal, is NOT equivalent to packing with 7zFM.exe with rate 9 if .exe and .dll files are involved

2ghisler(Author)
Could it be so that somehow the folder names pass differently to the internal or the external packer, because if the folders involved we always have the difference?

2ghisler(Author)
And there's something really wrong with a sorting:
If I create a file like this in 7-zip:
7z.exe a -mx7 file.7z file
7z.exe a -mx7 -mqs file.7z file
they are different and it's normal but for the internal packer -mmqs does nothing - the files are identical with or without it.

Maybe it would be better, and less misleading, if the choices for the "other" compression only offered the supported values 0, 1, 3, 5, 7, 9

petermad wrote: 2024-11-09, 11:15 UTC Maybe it would be better, and less misleading, if the choices for the "other" compression only offered the supported values 0, 1, 3, 5, 7, 9

Yes, that would be proper.

One more google-translated post from other forums:
When 7z.dll requests kpidPath, TC returns the name with a backslash at the end, but it should be without it. That is, it should return "7z2408-x64", not "7z2408-x64\". Fix this. If it doesn't help, we'll look some more.
Hope, that can help...

2MaxX
Yes, and for the other forum where me talking to Denis Anisimov, he previously clearly said that he didn't see -mmqs is passed to 7z.dll from the internal packer, this isn't right anyway.

When 7z.dll requests kpidPath

Which interface requests this? I searched the source of tcbit7z but there is no reference to kpidPath. There are 64 files containing a reference to kpidPath in the 7-Zip sources, so I don't know what exactly you are referring to.

for the internal packer -mmqs does nothing

The parser of the internal packer is a bit limited, so currently only
-mmqs=on
does something. -mmqs=off also works, but it's the default.

However, it looks like I'm misinterpreting the documentation: I assumed that
-mm0=LZMA
sets the compression method and
-mmqs=on
enabled sorting, but according to the 7-zip CHM help and https://7-zip.org/faq.html it should actually be -mqs.
Also according to the help -mm0=method is only used for ZIP archives but not for 7-zip, where it is defined as
{N}={MethodID}[:param1][:param2][..]

I will try to update the parser to support both the old and new format, e.g.
-mm0=LZMA (wrong)
-mm0=LZMA (correct)
-mmqs (wrong)
-mqs (correct)
-mqs=on (correct)
-mqs=off (correct)

Which interface requests this?

updatecallback.cpp, UpdateCallback::GetProperty

I searched the source of tcbit7z but there is no reference to kpidPath.

Search for BitProperty::Path instead.

2ghisler(Author)
7-zip's syntax is:

-m0=LZMA there's only one "m", literally means method. All the other setting with m are the subset of "Method" like -mhe=on or -mqs=on.
I thought double m like -mmqs is done for purpose. There are some examples at the bottom of 7-zip.chm - Switches - -m "Method".
We can't write it like -mmd=256m in "Extra Parameters" of TC and pass it to 7zG.exe - it'll be an error.

7z format supports different methods per archive, so it can be like -m0=BCJ2 -m1=LZMA2 -mN=
while Zip format has only one method per archive but the syntax is uniform: -mm=deflate64


Yes, there's no need to disable -mqs=off because it's a default value, we usually enable it like: -mqs=on or simply -mqs < these are equal.

2ghisler(Author)
Once again I would like to ask a very simple question - why are you knocking on an almost closed door? figuratively speaking?
Why not contact the developer personally? Perhaps some kind of reward would be more than a logical payment.
BUT you will receive immediate answers to all your questions.
Or do you think that a couple of months of reverse engineering of source codes is worth this torment with games of guessing “where and what”?

2Dec
I can confirm that cutting the trailing backslash in updatecallback.cpp, UpdateCallback::GetProperty makes the archive a tiny bit smaller. Apparently the 7-zip dll stores the backslashes in the archive and returns them when reading the archive, while 7zg.exe does not store the trailing backslashes.

2lelik007
Thanks for the clarification, I was confused by the documentation because for zip archives the parameter is actually -mm=Method. I will try supporting the possible parameters in the next beta.