[may be older, 11.03, 11.56] RAR -hp in RAR -p

[MaxX]

You'll need password protected RARs again.

I have some solid RARs with header encrypted (ask me password before I can see file names). Most of them have rar4 format.
Also I have the backup system that makes regular solid RARs with password, but I can see file names/sizes/blake sums. Then my backup system packs some working folders (incl. those first RARs) to some big archives.
That's how I get RAR in RAR. And I can't get any access into inside-rars from big archive because TC does not ask password for them at all, it just shows empty rar instead. I must extract them elsewhere, then RESTART TC, and only then can open them.

Example to try yourself:
Let them be
1.rar = solid, header encrypted (-hp), password is "1"
2.rar = solid, regular encrypted (-p), password is "2"
Now put 1.rar inside to the 2.rar and try to get inside it. That should give you the same experience.

TC 11.03 , TC 11.56 , Win 10 22H2 x64

[MaxX]

UPD:
I found that not all achieves (those as 1.rar in example) are affected.
Unfortunately I can't share my archives (sensitive and personal data). May be anyone have any ideas what could I do to find the reason.

UPD2:
I get this problem not only with TC 11.56 + unRAR 7.13 but also with old TC 11.03 + 6.24 version.
So looks like a problem in TC or unRAR DLL and is NOT related to new 7z issues.

UPD3:
Strange. It is definitely reproducible on my archives real work data archives, but I could not get an error with newly created sample rar.

UPD4:
If anyone else can check this with your old archives from RAR 3.x and 4.x ages, please, try some of them. Still can't understand what is going on.

UPD5:
I've also checked my archives for any corruption. No errors found, all data inside is valid. Winrar and 7zip have no problems there.

[MaxX]

UPD6:
I can reproduce the problem with "remember password" option on.
There's NO problem if the password is not being remembered.

[Horst.Epp]

UPD6:
I can reproduce the problem with "remember password" option on.
There's NO problem if the password is not being remembered.

That's what we expect.
If you don't use the same password for your nested archives your procedure will fail.
For such a job I use a long complicated password but always the same.
This works as designed.

[ghisler(Author)]

Could this be the same problem as the one described here?
https://www.ghisler.ch/board/viewtopic.php?t=86076

[MaxX]

It seems to be similar.
May be the difference is that I use password protected rars without header encryption here first time. Still I have never got any need to use those "-p" (not "-hp") before this new backup system.

[ghisler(Author)]

Example to try yourself:
Let them be
1.rar = solid, header encrypted (-hp), password is "1"
2.rar = solid, regular encrypted (-p), password is "2"
Now put 1.rar inside to the 2.rar and try to get inside it. That should give you the same experience.

I have tried this now, but I had no problems entering the inner archive in TC 11.56.
1. Open 2.rar -> no password needed
2. Open the inner 1.rar -> I'm first asked for the password of 2.rar, and then for the password of 1.rar.
Sample file: https://plugins.ghisler.com/sample/2.rar

Maybe I made a mistake creating one of the archives?
1.rar was created with parameters -s -hp
2.rar was created with parameters -s -p

[MaxX]

Sample file: https://plugins.ghisler.com/sample/2.rar

No problem here.

As I said in upd#1 there is a problem with some or rars, not all of them.
I still have not found a reason for such a difference.
Furthermore if I make some changes to the archive with this issue (e.g. I have there 3 txt files with logins+passwords and delete one of them), the new one has no problem then. Some of these "inner" rars (with "-hp") are old enough, made by RAR v3.x or v4.x (can't tell clearly, but it is definitely before any RAR 5 releases).
My backup system makes "outer" rars in RAR v.6 format (literally v.5 is the same) with simple "-m5 -s -p<password>" cmdline. May be some reason there. Not sure.
As far as I guess now (I could be wrong), it really may be related to my older report and presumably would be fixed with the fix of that older issue.

UPD2.
I would like to try to open my archives without unrar dlls (7z dll works then), but now I get too much password requests ("remember" is on, does not help) and have no chance to test such condition now. So can't check this now. But I can try it after that fix.

[ghisler(Author)]

now I get too much password requests

That's an indication that the RAR file consists of multiple solid blocks, e.g. the first 100 files were packed in one solid block, then the next 20 files in another solid block (added later or due to some pack parameters).

[MaxX]

2ghisler(Author)
I know that, of course.
Btw, I have multiple requests for once-made solid rars (never updated), but that might be normal for this archive format to use multiple blocks for different files or used filters for them, etc...

[ghisler(Author)]

The multiple requests happen because the 7z dll asks again for the password for each solid block. I need to filter that out. I was just working on that when the unrar.dll vulnerability became known, so I had to postpone the fix (my fix at the time eliminated the extra password requests, but made it impossible to abort the password input when the password was wrong or unknown, so it needed more work).
See:
https://www.ghisler.ch/board/viewtopic.php?t=86134

[ghisler(Author)]

This should be fixed in Total Commander 11.57 beta 1, please check it!

[MaxX]

Another related report seems to be ok now. But my specific nested rar is still shown empty IF unrar*.dll used.
I have tested (after the fix of multiple password requests works) the same actions without unrar*.dll (just deleted them). The same nested rar is shown correct then!

[ghisler(Author)]

Do you mean the sample file: https://plugins.ghisler.com/sample/2.rar from above?
I do not get this problem here, I'm first asked for the password of 2.rar, and then for the password of 1.rar.
Please describe more in detail how to reproduce your problem. Maybe a special wincmd.ini is needed?

[MaxX]

Sorry for misunderstand.
The sample 2.rar works fine now.
I've meant my personal archives:

UPD3:
Strange. It is definitely reproducible on my archives real work data archives, but I could not get an error with newly created sample rar.