Error occurred when deleting folders inside an encrypted 7-Zip archive.

[ghisler(Author)]

How about this: I could remember the names as long as one of the file panels or one of the other tabs shows the content of the archive. when reading a directory (or closing a tab), I check whether the archive is still open on any of the other tabs (or the user has decided to remember the password for that archive), and if not, I discard the names.

If you agree with this, then what about the following case:
1. The user has NOT checked the option "Return to locked tab root directory on tab change".
2. The user has a directory "Downloads" which he has locked with directory changes allowed.
3. When the user opens an archive in that tab with header-encrypted names, all he sees on the tab header is "!*Downloads", which doesn't give him a clue that it contains an open archive.
4. When he switches to a different tab and back, he would return to that header-encrypted archive.
Question: Should he be asked again for the password in this case?

[white]

2ghisler(Author)
When an archive contains password protected encrypted folder names, do you agree that TC should not store these names unencrypted in wincmd.ini?
And do you agree that these names should not be accessible in the navigation history after the archive is closed?

How about this: I could remember the names as long as one of the file panels or one of the other tabs shows the content of the archive. when reading a directory (or closing a tab), I check whether the archive is still open on any of the other tabs (or the user has decided to remember the password for that archive), and if not, I discard the names.

If you agree with this, then what about the following case:
1. The user has NOT checked the option "Return to locked tab root directory on tab change".
2. The user has a directory "Downloads" which he has locked with directory changes allowed.
3. When the user opens an archive in that tab with header-encrypted names, all he sees on the tab header is "!*Downloads", which doesn't give him a clue that it contains an open archive.
4. When he switches to a different tab and back, he would return to that header-encrypted archive.
Question: Should he be asked again for the password in this case?

When the contents of an archive is password protected and encrypted (including encryption of filenames), shouldn't it then be hard to access rather than easy? Wouldn't it be better if an archive is closed (navigated to outside the archive) as soon as the user switches to another tab?

Having multiple tabs where these kind of archives are open, doesn't seem to fit the chosen protection. If the user still sometimes would want to have such archives open multiple times at once, the user could open multiple TC instances to accomplish that.

[ghisler(Author)]

OK, since this is highly controversial, I have chosen to make it configurable!

The new option:
wincmd.ini [Packer] EncryptedNameCache=1
controls when to cache names in header-encrypted archive archive:
0=while archive open on current tab only,
1=while archive open on any tab,
2=always

0 is as suggested by 2white
1 is as suggested by myself, where I keep the cache while the archive is still open in any tab on the same side.
2 is as in previous Total Commander versions, e.g. for home PCs where there is no risk of stealing any data.

You may also like the new experimental option (not in the history.txt)
wincmd.ini [Packer] KeepPackerPassword=4
When 4 is added to KeepPackerPassword, forget the archive password when the user leaves the archive.

This way you can check the option to remember the password, and it will be forgotten as soon as you leave the archive.

Please let me know what you think!

[petermad]

29.05.26 Added: wincmd.ini [Packer] EncryptedNameCache=1 controls when to cache names in header-encrypted archive archive: 0=while archive open on current tab only, 1=while archive open on any tab, 2=always (32/64)

This new setting seems to solve the problem. Maybe setting 0 should be a bit more restrictive - right now with setting 0 if I am inside a header-encrypted archive and press Ctrl+T I am not asked for a password when loading the opened archive in the new tab - I think that is OK for setting 1 but not for setting 0.

[white]

2ghisler(Author)
When an archive contains password protected encrypted folder names, do you agree that TC should not store these names unencrypted in wincmd.ini?

2ghisler(Author)
This still happens. For example, a decrypted folder name in an inactive tab header is written to wincmd.ini when TC is closed. Do you agree that this shouldn't happen?

And do you agree that these names should not be accessible in the navigation history after the archive is closed?

28.05.26 Fixed: Do not store subdirs in header-encrypted 7-Zip or RAR archives in the history (32/64)

I have only tested this for 7-Zip files. It seems to work OK for header-encrypted 7-Zip files.

The new option:
wincmd.ini [Packer] EncryptedNameCache=1
controls when to cache names in header-encrypted archive archive:
0=while archive open on current tab only,
1=while archive open on any tab,
2=always

0 is as suggested by 2white
1 is as suggested by myself, where I keep the cache while the archive is still open in any tab on the same side.
2 is as in previous Total Commander versions, e.g. for home PCs where there is no risk of stealing any data.

It's not what I suggested. And I think this is the wrong approach. (And option 0 doesn't work when entering an archive, then pressing Ctrl+T, and then leaving the archive and entering it again.)

You may also like the new experimental option (not in the history.txt)
wincmd.ini [Packer] KeepPackerPassword=4
When 4 is added to KeepPackerPassword, forget the archive password when the user leaves the archive.

This way you can check the option to remember the password, and it will be forgotten as soon as you leave the archive.

I think this is going in the right direction. As I said:

Caching and keeping history should be disabled or brought back to the point that access is dependent on using the password, not whether or not names are cached or history is kept.

Please take this approach into consideration:

• Always lose the cache when leaving the archive or switching to a new tab.
  Then, a password is asked every time when entering a header-encrypted archive, or when switching to a tab with an open header-encrypted archive.
  This way the behavior is consistent and clear for the user. Access is controlled by the password, not by whether or not data is perhaps still in the cache (which is not transparent to the user).
• Add an option allowing to remember the password but always ask the password when entering a header-encrypted archive.
  Then, the user doesn't have to re-enter the password if access was granted earlier and the archive is still open on a tab. But when entering a header-encrypted archive, the password is always asked, even when the same archive is open on another tab.
  This again is consistent and clear behavior. Access has to be granted for each instance where the archive is opened, and the permission is given for the duration the archive is open.

[ghisler(Author)]

Thsi new setting seems to solve the problem. Maybe setting 0 should be a bit more restrictive - right now with setting 0 if I am inside a header-encrypted archive and press Ctrl+T I am not asked for a password when loading the opened archive in the new tab - I think that is OK for setting 1 but not for setting 0.

EncryptedNameCache=0 is currently implemented like this:
1. When you stay within the same archive, the encrypted names are cached
2. Once you step out of the archive, they are forgotten.
With Ctrl+T, or when switching between two tabs with the same archive, the archive stays the same, so the user will not be asked again for the password. The idea is that as long as the user sees the content of the archive, the names are cached. I find this more logical. I will change the description to:
0: Only while the archive is open in a file panel (separately for each side)

This still happens. For example, a decrypted folder name in an inactive tab header is written to wincmd.ini when TC is closed. Do you agree that this shouldn't happen?

I did not notice that, and will prevent it. I only prevented the subdirs and file names (for caret positioning) from being added to the history.

(And option 0 doesn't work when entering an archive, then pressing Ctrl+T, and then leaving the archive and entering it again.)

This works for me. With EncryptedNameCache set to 0, when I leave the archive after Ctrl+T, and try to enter it again, I'm asked for the password. Make sure to set EncryptedNameCache=0 in section [Packer], and do not check the option to remember the password, or set KeepPackerPassword=4.

Always lose the cache when leaving the archive or switching to a new tab.

But when you do Ctrl+T, you are not actually leaving the archive! The user always sees the archive content, so they see the names and know that they are cached. You are asked for the password when switching between two different header-encrypted archives.

Add an option allowing to remember the password but always ask the password when entering a header-encrypted archive.

This is what the combination of
EncryptedNameCache=0
and
KeepPackerPassword=4
does.

[petermad]

Something else:

If I (after restart) try to enter an encrypted archive and I in the dialog box "Password required!" press Cancel - then I get this message

---------------------------
Total Commander
---------------------------
Error in packed file f:\test1\bb\test.7z!
---------------------------
OK
---------------------------

I think it would be more logical just to close the "Password required!" dialog


If I have set KeepPackerPassword to 1, 2 or 3 - then the "Password required!" dialog still shows:

[ ] Remember (until progtram is closed or minimized)

would it be possible to remove the incorrect part in parenthesis in these cases? or would that require a new string? - only WCMD_BUL.LNG and WCMD_JPN.LNG does not use a parenthesis in string 5006

[white]

(And option 0 doesn't work when entering an archive, then pressing Ctrl+T, and then leaving the archive and entering it again.)

This works for me. With EncryptedNameCache set to 0, when I leave the archive after Ctrl+T, and try to enter it again, I'm asked for the password. Make sure to set EncryptedNameCache=0 in section [Packer], and do not check the option to remember the password, or set KeepPackerPassword=4.

Sorry, I made the mistake of putting the setting under the wrong section. EncryptedNameCache=0 seems to work as designed.

Always lose the cache when leaving the archive or switching to a new tab.

But when you do Ctrl+T, you are not actually leaving the archive! The user always sees the archive content, so they see the names and know that they are cached. You are asked for the password when switching between two different header-encrypted archives.

I understand your EncryptedNameCache=0 implementation now and I think that it's probably an acceptable solution. But I meant to say that I think that the approach of having the multiple EncryptedNameCache options is wrong. I asked to consider doing away with the EncryptedNameCache options and having it always work like EncryptedNameCache=0, and to offer the user a similar experience through a remember password setting.

The point is that caching should not circumvent or replace password protection. Consider the situation when using EncryptedNameCache=2 and working with no tabs at all. Just enter an archive, type the password and do not select remember password. When done with the archive, leave the archive. When at a later time an attempt is made to enter the archive again, no password is asked (as long a no other archive was entered in between). In this case, caching circumvents the password protection to gain access for a longer period.

Now consider the situation when using EncryptedNameCache=1 (the default now) and not using the option to remember the password. An argument could be made that when the user typed the correct password, access is meant to be granted for this archive on all tabs, and for the duration that the archive is open on any of the tabs. However, then the user should always have access to the archive when the archive is open on any of the tabs, but this is not the case. Sometimes the password is asked and sometimes not, depending on the content of the cache. This makes the cache the gatekeeper of the archive instead of the password. And the user must be aware that access is granted for the duration the archive data is in the cache. I think this is not at all obvious and and very confusing to users.

I think it can also fool people into thinking their data is protected when it is not. Suppose a user enters his protected archive, types in the password, leaves the archive, enters some other archive, leaves that archive and then tries to enter his protected archive again. In this case the user is asked for his password again. This may cause the user to think that the password will always be asked after leaving the archive. He types in his password again, and after doing some work, he leaves the archive again. Now he walks away from his desk thinking his archive is protected. Now another person comes along and opens the archive without a password being asked.

Add an option allowing to remember the password but always ask the password when entering a header-encrypted archive.

This is what the combination of
EncryptedNameCache=0
and
KeepPackerPassword=4
does.

Forgetting the archive password when the user leaves the archive is not necessarily the same thing as always asking for the password when entering the archive. For example, when having the archive open on multiple tabs. I don't know if it amounts to the same thing in your implementation. I tested above combination and it did not work. TC kept asking for the password after switching to another tab with normal folder contents and then back again to a tab with an open archive.

[ghisler(Author)]

If I (after restart) try to enter an encrypted archive and I in the dialog box "Password required!" press Cancel - then I get this message

Error in packed file f:\test1\bb\test.7z!

That's because the 7-zip unpacker returns an error as if the archive was bad when entering the wrong password. I can try to set a flag when the user clicks on Cancel.

would it be possible to remove the incorrect part in parenthesis in these cases?

This is difficult because some of it still applies when using option 1 or 2. I will leave it as it is for now.

Sorry, I made the mistake of putting the setting under the wrong section. EncryptedNameCache=0 seems to work as designed.

Great!

But I meant to say that I think that the approach of having the multiple EncryptedNameCache options is wrong.

People's requirements are always different. For me it's essential to keep the archive open when it's on a different tab, so I can quickly switch tabs for other things.

The point is that caching should not circumvent or replace password protection.

It does it only for the file names, not for the file content. Entering the password for each directory change within the archive would be unusable.

Consider the situation when using EncryptedNameCache=2

I do not recommend using EncryptedNameCache=2 any more. I only added it for people who want the old behavior back and would refuse to update, missing a lot of other fixes in the process.

Sometimes the password is asked and sometimes not, depending on the content of the cache.

Indeed the cache only handles a single archive on each side. So when you have multiple header-encrypted archives open on the same side, you will be asked for the password each time you switch between them. This could only be solved by storing the name cache separately for each tab, but it would have other negative effects. Therefore having a cache for just one archive is a reasonable compromise.

I think it can also fool people into thinking their data is protected when it is not. Suppose a user enters his protected archive, types in the password, leaves the archive, enters some other archive, leaves that archive and then tries to enter his protected archive again. In this case the user is asked for his password again. This may cause the user to think that the password will always be asked after leaving the archive. He types in his password again, and after doing some work, he leaves the archive again. Now he walks away from his desk thinking his archive is protected. Now another person comes along and opens the archive without a password being asked.

No, that should not happen when the archive isn't open in the current tab (EncryptedNameCache=0), or any tab (EncryptedNameCache=1). That was the whole point of EncryptedNameCache=0/1.
Please let me know if you find a scenario where this happens.

Forgetting the archive password when the user leaves the archive is not necessarily the same thing as always asking for the password when entering the archive.

Total Commander checks both when the user leaves the archive an when he re-enters an archive to make sure that it doesn't happen.

I tested above combination and it did not work. TC kept asking for the password after switching to another tab with normal folder contents and then back again to a tab with an open archive.

When using

KeepPackerPassword=4

You need to check the option "Remember (until program is closed...)" to keep the password in this case. TC shows the extra text (File) at the end to tell the user that it's only remembered for that file.

[white]

But I meant to say that I think that the approach of having the multiple EncryptedNameCache options is wrong.

People's requirements are always different.

It's not about people's requirements. It's about secure software design and about behavior that is clear to the user.
An important security setting requiring users to know when Total Commander is caching data is incorrect IMO. Users often do not know what caching is, and should not be required to know what caching is in order to keep their data safe.

For me it's essential to keep the archive open when it's on a different tab, so I can quickly switch tabs for other things.

I am not suggesting much different. But I am suggesting consistent behavior, not that a password is sometimes asked (data no longer in the cache) and sometimes not (data still in the cache). The only difference is that the cache is discarded quicker. A consistent easy access to an open archive can still be achieved by a remember password setting. There would be a performance difference of course, but that seems like a reasonable compromise.

The point is that caching should not circumvent or replace password protection.

It does it only for the file names, not for the file content.

Are you suggesting that encrypted filenames are less important than encrypted file content?

Entering the password for each directory change within the archive would be unusable.

Depending on what you mean by that, I did not suggest that.

Consider the situation when using EncryptedNameCache=2

I do not recommend using EncryptedNameCache=2 any more. I only added it for people who want the old behavior back and would refuse to update, missing a lot of other fixes in the process.

If that's how you feel, wouldn't it be better to add "(not recommended)" to the help text for this option?

Sometimes the password is asked and sometimes not, depending on the content of the cache.

Indeed the cache only handles a single archive on each side. So when you have multiple header-encrypted archives open on the same side, you will be asked for the password each time you switch between them.

That's far from the only possible scenario. For example, if you switch to a tab with normal folder content, enter an unprotected archive, leave the archive, and then switch back to the tab with the header‑encrypted archive, you will be asked for the password too.

I think it can also fool people into thinking their data is protected when it is not. Suppose a user enters his protected archive, types in the password, leaves the archive, enters some other archive, leaves that archive and then tries to enter his protected archive again. In this case the user is asked for his password again. This may cause the user to think that the password will always be asked after leaving the archive. He types in his password again, and after doing some work, he leaves the archive again. Now he walks away from his desk thinking his archive is protected. Now another person comes along and opens the archive without a password being asked.

No, that should not happen when the archive isn't open in the current tab (EncryptedNameCache=0), or any tab (EncryptedNameCache=1). That was the whole point of EncryptedNameCache=0/1.
Please let me know if you find a scenario where this happens.

Sorry, I wasn't clear. I was still talking about the situation when using EncryptedNameCache=1 (the default) and I meant that the user had the archive open on another tab too and then did those things.

Forgetting the archive password when the user leaves the archive is not necessarily the same thing as always asking for the password when entering the archive.

Total Commander checks both when the user leaves the archive an when he re-enters an archive to make sure that it doesn't happen.

Then it could be different than what I am suggesting.

I tested above combination and it did not work. TC kept asking for the password after switching to another tab with normal folder contents and then back again to a tab with an open archive.

When using

KeepPackerPassword=4

You need to check the option "Remember (until program is closed...)" to keep the password in this case. TC shows the extra text (File) at the end to tell the user that it's only remembered for that file.

I have enabled Remember password and I see the text "(File)" at the end, but it is not doing what I expect. Can you give me an example to test that demonstrates how it is supposed to work?

[ghisler(Author)]

An important security setting requiring users to know when Total Commander is caching data is incorrect IMO. Users often do not know what caching is, and should not be required to know what caching is in order to keep their data safe.

That's why there are predefined options. I think the current default options are fine. People can change them if they want less or more caching, but it's not a requirement.

Are you suggesting that encrypted filenames are less important than encrypted file content?

Yes, they may give some clues to what is in the files, but not give you the content.

If that's how you feel, wouldn't it be better to add "(not recommended)" to the help text for this option?

I will add it.

That's far from the only possible scenario. For example, if you switch to a tab with normal folder content, enter an unprotected archive, leave the archive, and then switch back to the tab with the header‑encrypted archive, you will be asked for the password too.

That's the same reason: Only one archive is cached at the same time in a file panel.

Sorry, I wasn't clear. I was still talking about the situation when using EncryptedNameCache=1 (the default) and I meant that the user had the archive open on another tab too and then did those things.

That's the point of EncryptedNameCache=1: Keep the cache as long as the archive is open on any of the tabs.

I have enabled Remember password and I see the text "(File)" at the end, but it is not doing what I expect. Can you give me an example to test that demonstrates how it is supposed to work?

When you check "Remember password" with KeepPackerPassword=4, the password will not only be forgotten when minimizing TC or the program is closed, but also when you leave the archive. This allows you to preserve the password to do various operations, e.g. create multiple new folders, add files, rename files, delete files etc. without being asked for the password until you close the archive.

Example 1:
1. Enter a header-encrypted archive -> choose to NOT remember the password
2. Try to create a new directory -> you will be asked again for the password 3 times (once to open the archive, once to pack, and once to re-open the modified directory)

Example 2:
1. Enter a header-encrypted archive -> choose to remember the password
2. Try to create a new directory -> you will NOT be asked again for the password
3. Leave archive
4. Enter archive -> you will be asked again for the password

If you don't set KeepPackerPassword=4, then in Example 2 steps 1 to 3 will be the same, but in step 4, you will not be asked for the password because it's being remembered until you close or minimize Total Commander.

[ghisler(Author)]

I want to get back to your suggestion above:

Now consider the situation when using EncryptedNameCache=1 (the default now) and not using the option to remember the password. An argument could be made that when the user typed the correct password, access is meant to be granted for this archive on all tabs, and for the duration that the archive is open on any of the tabs.

The problem with this is that I would need to save the password although the user has unchecked the option. I think I should communicate that to the user. It would probably require separate checkboxes:
- remember password for current file until closed
- remember (until program is closed or minimized)

I think that this would be worth adding. Unfortunately this would require translation, and I don't want to delay 11.58 for months when currently essential functions like cm_FocusLeft are broken in 11.57.

So I think I will keep the current approach for now. Is there anything I could improve with the current approach? Maybe I should make EncryptedNameCache=0 the default?

[AntonyD]

EncryptedNameCache=0 the default?

imho yes.

[white]

An important security setting requiring users to know when Total Commander is caching data is incorrect IMO. Users often do not know what caching is, and should not be required to know what caching is in order to keep their data safe.

That's why there are predefined options. I think the current default options are fine. People can change them if they want less or more caching, but it's not a requirement.

With the current default setting, it is a requirement for users to understand what is happening. I understand that you are fully aware of how Total Commander works, but the user is not. To the user, Total Commander behaves inconsistently: sometimes a password is requested before password-protected content is shown, and sometimes not. In addition to being very confusing for the user, there is also a real chance that this behavior leads the user to believe that Total Commander will ask for a password and that their content is secure, when this is not the case, resulting in a security breach.

Are you suggesting that encrypted filenames are less important than encrypted file content?

Yes, they may give some clues to what is in the files, but not give you the content.

Filenames may be equally important to the user or even more important than file content. The 7-Zip specification doesn't say that filenames shouldn't contain important information.

File content en filenames are both password protected and encrypted. The user should be able to rely on that information contained in both are handled with the same care.

That's far from the only possible scenario. For example, if you switch to a tab with normal folder content, enter an unprotected archive, leave the archive, and then switch back to the tab with the header‑encrypted archive, you will be asked for the password too.

That's the same reason: Only one archive is cached at the same time in a file panel.

I know. I meant to convey that it happens much more often than your example suggests.

Sorry, I wasn't clear. I was still talking about the situation when using EncryptedNameCache=1 (the default) and I meant that the user had the archive open on another tab too and then did those things.

That's the point of EncryptedNameCache=1: Keep the cache as long as the archive is open on any of the tabs.

Yes, you know that. But users do not live inside your head and do not know. They have no knowledge of EncryptedNameCache=1 and what it means, which causes confusion and could lead to a data breach.

I have enabled Remember password and I see the text "(File)" at the end, but it is not doing what I expect. Can you give me an example to test that demonstrates how it is supposed to work?

When you check "Remember password" with KeepPackerPassword=4, the password will not only be forgotten when minimizing TC or the program is closed, but also when you leave the archive. This allows you to preserve the password to do various operations, e.g. create multiple new folders, add files, rename files, delete files etc. without being asked for the password until you close the archive.

Unlike what you claimed, that is different from what I suggested. It seems you have been dismissing things without understanding what you were dismissing.

The content of a header-encrypted archive is protected by a password. I think each time such archive is opened, in any tab, the password should be asked (unless the user enabled the option to always remember the password), even when the archive is already open in another tab. This way, there is always explicit permission to open an archive in a tab. This prevents accidental opening the archive in a new tab, opening in a new tab by the cat interfering, or by foul play (for example, pressing Ctrl+Up without the user noticing). I think just because there is permission to open an archive in the current tab, doesn't mean it can be assumed the user gave implicit persmission for opening the archive in additional tabs as well.

If the user wants to have a protected archive open in 3 tabs, he must enter the password 3 times. This may not be the most convenient, but I think this is fitting for an header-encrypted archive.

Tab switching where a protected archive is already open in multiple tabs can behave as is currently the case with EncryptedNameCache=0.

To avoid having to type the password again when access was already granted in a tab, I suggested a new remember password setting, but not like your KeepPackerPassword=4 setting. While your setting forgets the password when leaving an archive, my suggested setting only forgets the password when leaving the last open protected archive. When explicit permission is given for each time an archive is opened, the password is remembered for all these instances. But when the user tries to enter the archive in a tab, then the password is forgotten, because permission hasn't been granted for this instance yet.

So I think I will keep the current approach for now. Is there anything I could improve with the current approach? Maybe I should make EncryptedNameCache=0 the default?

The default option should definitely be secure. In my opinion the current behavior of EncryptedNameCache=0 isn't even secure enough. As said, I think permission to open a protected archive in a tab cannot be assumed to automatically also mean permission to open the protected archive limitless on additional tabs. I feel the situation where an assumption like that could lead to a data breach for the user should be avoided.

[ghisler(Author)]

Unlike what you claimed, that is different from what I suggested. It seems you have been dismissing things without understanding what you were dismissing.

I'm sorry but I really must have understood your actual point. There are so many posts from you that I have lost the overview.

I think each time such archive is opened, in any tab, the password should be asked

If that is your point, then I have to disagree. KeepPackerPassword=4 is not about tabs at all. It only distinguishes between the case when the header-encrypted archive is currently shown in the active panel, and when it is not shown. The password is asked when you switch from the second state (not shown) to the first (shown). The method how you switch between these two states does not matter, because there are so many:
- switching between directories within the same archive
- switching between tabs with the same archive
- switching to different directories within the archive via command line
- switching to different directories within the archive via bookmarks (directory hotlist)
- switching to different directories within the archive via start menu "cd" command
- switching to different directories within the archive via history
- switching to different directories within the archive via button bar "cd" command
- switching to different directories within the archive by receiving the directory via command line parameters /O /L= or /O /R=

All that matters is that you stay within the same archive. I don't see why just the tab switch should be treated differently. The help for option 4 explains that too:
4: When added, forget the archive password when the user leaves the archive

To avoid having to type the password again when access was already granted in a tab, I suggested a new remember password setting, but not like your KeepPackerPassword=4 setting. While your setting forgets the password when leaving an archive, my suggested setting only forgets the password when leaving the last open protected archive.

So you mean that passwords need to be remembered per TAB, not per archive, and discarded once the user leaves the archive on that tab. I think that this is counter-intuitive. Users mostly know tabs from Web browsers, and there logging in to a web size applies to all tabs. But there is no automatic logout, so the comparison isn't fully applicable.

The default option should definitely be secure. In my opinion the current behavior of EncryptedNameCache=0 isn't even secure enough. As said, I think permission to open a protected archive in a tab cannot be assumed to automatically also mean permission to open the protected archive limitless on additional tabs.

I really don't understand your obsession with tabs. For the user, it's unintuitive when they need to re-enter the password although the archive is currently open before their eyes. It's beyond my imagination why you consider this insecure, sorry.