Hammerfest

Igor, I don't think you are fully reading whats going on. We do NOT WANT to LIMIT the RAM USED, it results in LARGER archive size's OR (now) LONGER compression times! Bug#1: You added a CRUDE ASSUMPTION calculation that says, "with these parameters, it WILL use X memory, CHECK memory capacity, if lower, DISPLAY ERROR AND STOP (it SHOULD NOT DO THIS), DESPITE the fact the operation WILL NOT USE EVEN CLOSE to the displayed memory REQUIRED (aka, its NOT REQUIRED, and is an ASSUMPTION and a WRONG one...

Igor, I don't think you are fully reading whats going on. We do NOT WANT to LIMIT the RAM USED, it results in LARGER archive size's OR (now) LONGER compression times! Bug#1: You added a CRUDE ASSUMPTION calculation that says, "with these parameters, it WILL use X memory, CHECK memory capacity, if lower, DISPLAY ERROR AND STOP (it SHOULD NOT DO THIS), DESPITE the fact the operation WILL NOT USE EVEN CLOSE to the displayed memory REQUIRED (aka, its NOT REQUIRED, and is an ASSUMPTION and a WRONG one...

Igor, I don't think you are fully reading whats going on. We do NOT WANT to LIMIT the RAM USED, it results in LARGER archive size's OR (now) LONGER compression times! Bug#1: You added a CRUDE ASSUMPTION calculation that says, "with these parameters, it WILL use X memory, CHECK memory capacity, if lower, DISPLAY ERROR AND STOP (it SHOULD NOT DO THIS), DESPITE the fact the operation WILL NOT USE EVEN CLOSE to the displayed memory REQUIRED (aka, its NOT REQUIRED, and is an ASSUMPTION and a WRONG one...

This does NOT resolve the issue. You have built in a check to say "these settings will use this amount of ram, if this amount of ram isn't there, don't continue AT ALL. No "memory usage" limit I tried let me continue ANYWAY as it SHOULD. For Hyper-V with dynamic memory, and for operations who WONT actually USE that much RAM, its an ASSUMPTION that SHOULD NOT be a solid wall. Again, see screenshots and file size listings for LITERAL PROOF that this is BROKEN and truly a BUG or even REGRESSION to ...

As already reported in .04, and also in .03 7Zip incorrectly ASSUMES that it will not have enough RAM to complete a compression job and DOES NOT ALLOW IT to occur AT ALL instead of what it SHOULD do which is ALLOW the USER to CHOSE to continue ANYWAY (or a setting to ignore it completely). https://sourceforge.net/p/sevenzip/discussion/45797/thread/ba29828ce0/#3c6c This results in larger archives making 7Zip create larger archives then the competition and longer compression times.

Reporting again since it was reported in 21.03. Need an override of some sort to the memory check feature. In Hyper-V Memory scales, so it should NOT ASSUME that there isn't enough memory In NON-Hyper-V scenario's, it should NOT ASSUME that the max memory for settings chosen is ABSOLUTE, it ABSOLUTELY isn't! A simple real world example I do on anything thats pre-compressed that I stick in my IT toolkit: Download from AMD.com the latest Video driver (in my case today, 21.10.4) Extract it to a folder...

Reporting again since it was reported in 21.03. Need an override of some sort to the memory check feature. In Hyper-V Memory scales, so it should NOT ASSUME that there isn't enough memory In NON-Hyper-V scenario's, it should NOT ASSUME that the max memory for settings chosen is ABSOLUTE, it ABSOLUTELY isn't! A simple real world example I do on anything thats pre-compressed that I stick in my IT toolkit: Download from AMD.com the latest Video driver (in my case today, 21.10.4) Extract it to a folder...

Reporting again since it was reported in 21.03. Need an override of some sort to the memory check feature. In Hyper-V Memory scales, so it should NOT ASSUME that there isn't enough memory In NON-Hyper-V scenario's, it should NOT ASSUME that the max memory for settings chosen is ABSOLUTE, it ABSOLUTELY isn't! A simple real world example I do on anything thats pre-compressed that I stick in my IT toolkit: Download from AMD.com the latest Video driver (in my case today, 21.10.4) Extract it to a folder...