[TC 11.00b4] Pack with encryption, operation not unpaused when switching between foreground and background during verify

[AntonyD]

Ok for my report I think I found the roots.
LzmaAllowed=1
and choose Compression rate=10. And you will get this dump....

BTW as I see phrase "Compression rate" is NOT yet in ENG strings resource file?

[Sir_SiLvA]

there was no eng.lng-file in beta its string 5495="Compression rate"

[ghisler(Author)]

2white
Thanks for the animated gif, I can reproduce it now! It happens when I try to pack a directory. You wrote "Select an amount of files", so I selected a few big files - no problem with that.

2AntonyD
This is an unrelated bug, it's because of a buffer which the lzma packer uses for AES, but the new libdeflate packer doesn't.

[white]

It happens when I try to pack a directory. You wrote "Select an amount of files", so I selected a few big files - no problem with that.

I can reproduce it too with only files.

[ghisler(Author)]

I still can't.

[AntonyD]

2white
Let's step aside a little - did you manage to repeat MY bug?
And then all of a sudden, something is wrong.

[white]

2AntonyD
I can confirm your bug, but Ghisler already confirmed it too.

[AntonyD]

3 is better than 1 )))

[ghisler(Author)]

I found the problem with the hanging dialog! Actually the verification finishes normally, the verify function just doesn't pass the new dialog box handle to the unpack thread. This only happens when verifying an archive with a lot of small (but not too small) files. Then the "go to background/foreground" can happen AFTER the verification step. I tested only with a few very big files, so the "go to background/foreground" always happened in the middle of a file, which worked just fine. Anyway, there is a very simple fix for that, just catch the "go to background/foreground" at the end of a file too...

[white]

[white]

Tested both problems in this thread. There seems to be no descriptions of these fixes in HISTORY.TXT.

My problem: Tested OK using TC 11.00b5 32-bit and 64-bit

AntonyD's problem:

Tested OK using TC 11.00b5 64-bit
AV when using the 32-bit version:

---------------------------
Total Commander 11.00b5
---------------------------
Fatal error in zip thread, aborting!
Invalid pointer operation
Windows 11 Professional 10.0 (Build 22621), base: 00400000

Please report this error to the Author, with a description
of what you were doing when this error occurred!

Delphi exception: EInvalidPointer
Stack trace:
74E58462

Raw:
004026AC 00402D5C 00402732 004237CD 004237D6 0041FCB7
0041FCDB 005C002C 004230C7 00403440 00402229 >00419D09
0040369C
Press Ctrl+C to copy this report!
---------------------------
OK
---------------------------

[AntonyD]

AV when using the 32-bit version:

YES, is still here:
---------------------------
Total Commander 11.00b5
---------------------------
Fatal error in zip thread, aborting!
Invalid pointer operation
Windows 10 EnterpriseS 10.0 (Build 17763), base: 00400000

Please report this error to the Author, with a description
of what you were doing when this error occurred!

Delphi exception: EInvalidPointer
Stack trace:
74955432

Raw:
004026AC 00402D5C 004091BB 00402732 004237CD 004237D6
0041FCB7 0041FCDB 0044001E 004230C7 0057F2BE >00419D09
0040369C
Press Ctrl+C to copy this report!
---------------------------
ОК
---------------------------

[ghisler(Author)]

Indeed this should have been fixed on 25.5.2023, it's missing from the history for unknown reasons.
The problem was when a ZIP unpack or verify operation was moved to the background between two files (one just finished), the new dialog box handle was not passed to the unpack thread, so it still tried to send the update messages to the no longer existing foreground window. The same could happen when moving the operation from background to foreground.

[white]

25.05.23 Fixed: Moving a ZIP unpack or verify operation to the background between two files could cause a loss of updates of the operation (32/64)

History line added OK.

AntonyD's problem:

Tested OK using TC 11.00b5 64-bit
AV when using the 32-bit version:

Tested OK using TC 11.00b6 32-bit.

05.06.23 Fixed: Packing with ZIP method 10 (LZMA) and AES encryption caused access violation, sometimes in verification step (32)

Isn't this description wrong? The AV error was at the end of packing the first file, not during the verify phase. And not sometimes, but always?

[AntonyD]

Tested OK using TC 11.00b6 32-bit.

yes, indeed now with TC 32bit there is no AV crash.