[11.50 b3] Problem with high values of dictionary size for internal packer

[Hon_za]

Hi,

just checking 11.50 b3 with internal 7-zip packer, LZMA2, word size: 273
Values of Dictionary size: 2048, 3072 and 3840M give error: Cannont set the dictionary size: Invalid dictionary size for the chosen compression method.

1536M and lower values are OK.


EDIT: Values in WINCMD.INI are corresponding with GUI values.
7ZwordSizeLZMA2_9=273
7ZdictSizeLZMA2_9=3840
7Zextra=-stl

[ghisler(Author)]

Thanks for your report. This is a limitation in the used library bit7zip:
https://github.com/rikyoz/bit7z/blob/master/src/bitabstractarchivecreator.cpp
It seems to limit the maximum to 1536 megabytes.
I will change it. Seems like the maximum supported was changed in 2021:
https://sevenzip.sourceforge.io/history.txt

I have also submitted a bug report:
https://github.com/rikyoz/bit7z/issues/256

[MaxX]

2ghisler(Author)
Do we need bit7z lib at all? What is a reason?
Can't we just use original 7z.dll and 7z.exe just the same way as we use unrar.dll and rar.exe ?

[ghisler(Author)]

I use bit7z to interface with 7z.dll because the interface isn't documented anywhere and is very complex and confusing to call. I managed to call 7z.dll directly for unpacking, but I could not figure out how to call it for packing.

[MaxX]

2ghisler(Author)
I mean whis way:
UNpack -> use 7z.dll (just the same as unrar.dll)
Pack -> use 7z(g).exe (just the same as rar.exe)
Not only the dll for all cases.
That also should help to prevent any memory issues in packing progress. Extental process of the packer should be bore stable and even secure, I believe.
So I assume that there should be no need in additional bit7z library. Less files, same size. Easier updates of 7zip by the user. And for developer too.
Also that should help for legacy OS like win 9x...XP to get all supported by 7z.exe/7z.dll features without any problems of bit7z.

[AntonyD]

2MaxX
Yes! this is your offer MUCH better than what has been done now.

[Usher]

2MaxX
Support++
Could you create topic in Suggestions forum, please?

[MaxX]

2Usher
Here we go: viewtopic.php?t=84280

[ghisler(Author)]

I mean whis way:
UNpack -> use 7z.dll (just the same as unrar.dll)
Pack -> use 7z(g).exe (just the same as rar.exe)

That's exactly what happens when you uncheck "Use internal 7-Zip packer".

[MaxX]

So do I understand right?
I can uncheck option and delete bit7z dlls. Or not?

[AntonyD]

2ghisler(Author)
And why then the "7Z" checkbox on the "ZIP packer" tab presents?
If we have a completely separate working option to use a third-party whole software product 7-Zip?
after unchecking the "Use internal 7-Zip packer" checkbox.

[petermad]

And why then the "7Z" checkbox on the "ZIP packer" tab presents?

That if for using 7zG.exe (or 7z.exe) to make ZIP files (not for making 7Z files)

[Hon_za]

Guys, not everybody has trird-party packing software and it is quite often prohibited in corporate enviroment due to licence limitation of corporate end users knowlege/skill limitation; using TotalCD on basic level like connecting to FTP and packing to ZIP is top level what you can expect.
And not all features in external packer are working - like set date of packed file to newest file date.

For those reasons, I really appreciate feature to have internal 7ZIP packer in Total Commander.

Let's move back to initial issue - Problem with high values of dictionary size for internal packer.

Ratinale for using large dictionry size.
I have several users/computers with 32 or 64GB RAM that still use ZIP in TotalCMD.
They are compressing large folders on regular basis, graphics files for DTP etc.
Using 7ZIP in TotalCMD would save me a lot of disk space and usually solve problem when packed file doesn't fit on DVD.
It is not unusual that 7ZIP is half the size of ZIP.
This would also make transparent of how old are the files within 7ZIP, which is very relevant for our usage.

I have some automatic daily backups that has over 2GB in size - already somehow packed with proprietary format.
When archiving them with 2+GB dictionary size, their shrink in unbelievable way, beucase 99% of data are the same as previous days.
ZIP or 7ZIP with smaller dictionary size has no chance but 7ZIP with large dictionary size makes miracles.

[AntonyD]

2petermad
Still not clear - once again => once again support for working with the PRODUCT is offered and introduced! it's=7-ZIP,
then this means that when configuring it, we will be able to dynamically set those variants of archives,
that we need to create on its behalf. Because it is OBJECTIVELY becoming available.
Including its settings dialogs. OR not? Because as it seems to me - not everything is realized simply in code yet.
That's when we need to STRICTLY distinguish between the capabilities provided by Total to support the work of
the ONLY with ZIP archives (internally), OR with a LARGE variety of archives - but with an external product,
specifically 7-ZIP.

[ghisler(Author)]

Let's move back to initial issue - Problem with high values of dictionary size for internal packer.

That issue has already been resolved for the next beta.