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

[ghisler(Author)]

First, it's not only about filenames, but also about decrypted folder names in tab headers and the existence of additional opened tabs for the archive contents.

Well, there are two cases here:
1. If you duplicate a tab in the foreground, you see yourself that the header in the foreground shows the encrypted folder name
2. If you duplicate a tab in the background, you don't necessarily see it, but you willingly opened it in the background. The only way to prevent that would be to completely forbid opening of subdirs in header-encrypted archives in the background, because you would only be asked for the password when you switched to that tab. I think that this is a bit too limiting. It wouldn't make sense to ask for a password when opening such a tab in the background, and then again when actually switching to that tab.

Second, you seem to view this with a single-user and single-computer mindset. Which settings exist and which one is active may not be known to the user. One computer might be working with a specific setting, while another computer is working with a different setting. Or a user might change a setting without another user being aware of it. This can lead users to believe that their data is inaccessible, when in fact it is accessible.

You get a different "Remember" password checkbox when KeepPackerPassword is set to 4.

[AntonyD]

2AntonyD
What's your point? Where do you disagree with my above points 1 and 2? Just insulting me will not help me to figure out what you want changed.

I just simply completely agree with white.
Tnis problem with archives MUST BE widely presented in all possible places: Help, tooltips for gui elements, changelog, site, actions at the Total itself.
Any arguments AGAINST of it - is a very bad decision...
To say a little here is equal to say nothing...

In your current responses, you insist that enough has already been done so that users themselves understand everything and immediately begin working with such archives as they want.
But no, not enough has been said or shown. And no changes have been made to the program's interface that would close most of the security holes in this problematic case.
Even the very fact that you are ready to wait who knows how long for the next release, Just not supporting password lifetime management GUI options in the settings dialog is ALREADY unreasonable behavior.

WHITE - He simply knows how to explain his position well and clearly. I'm tongue-tied. And given the translations of phrases into another language, I might even make mistakes. So that's why I don't actively participate. Incomplete understanding of the problem is unacceptable in this topic...

[ghisler(Author)]

But no, not enough has been said or shown.

You say this, but you leave me completely hanging. What exactly isn't explained enough? What should be improved?

WHITE - He simply knows how to explain his position well and clearly.

I simply cannot implement what he requests, it's 100% impossible. It's simply not how tabs work in Total Commander! It's not like in a web browser where tab content is preserved when switching between tabs. They work more like bookmarks, so when you click on a tab, Total Commander has to read the directory for this tab. This is what makes his suggestions impossible to implement.

And that's why I'm desperately trying to find a solution which is understandable for users. That's why you get my two options described above. I can't implement WHITE's solution now, therefore I need input of what's wrong with my above solution.

WHITE has already commented about the folder names in the tab headers. What I could do here is to always revert to the archive root when the user duplicates a tab - either when it's duplicated in the background (so it may not be visible), or also when duplicated in the foreground. I will also not put these folders in the recently closed tabs. What else do you expect?

[ghisler(Author)]

2white
Unfortunately the approach you suggest is technically impossible with how Total Commander currently works: Tabs act more like
temporary bookmarks, the actual directory content is not stored per tab.

Therefore I would like to hear how I can get your approval for my approach where entering a header encrypted archive for the first
time will ask you for the password, but not when switching between tabs where this archive is already open.

As I understand, your main problem with this approach is that the user may open a tab where the header shows an encrypted subdirectory.

My suggestion to improve the security is the following:
1. Removed the EncryptedNameCache option, so the cache is only kept as long as the archive is currently displayed (option 0)
2. When the user opens a new tab in the background, and the new tab would show a subdirectory of a header-encrypted archive, then revert the tab to the root of the archive
3. When the user opens a new tab in the foreground, the user will immediately see the name in the header, so it should be allowed
4. Do not add closed tabs from header-encrypted archives to "Previously open tabs"

Are there still flaws in this suggestion?

[white]

2. If you duplicate a tab in the background, you don't necessarily see it, but you willingly opened it in the background.

As mentioned multiple times, "willingly opened it in the background" doesn't have to be the case. It's not reasonable to assume that this is always the case.

Second, you seem to view this with a single-user and single-computer mindset. Which settings exist and which one is active may not be known to the user. One computer might be working with a specific setting, while another computer is working with a different setting. Or a user might change a setting without another user being aware of it. This can lead users to believe that their data is inaccessible, when in fact it is accessible.

You get a different "Remember" password checkbox when KeepPackerPassword is set to 4.

This was also a reaction to your first point. It's not about remembering passwords. It is about that it is reasonable to assume that a user may encounter fluctuating TC behavior or insecure TC behavior resulting from different values ​​of the EncryptedNameCache setting, without the user being aware of this.

My suggestion to improve the security is the following:
1. Removed the EncryptedNameCache option, so the cache is only kept as long as the archive is currently displayed (option 0)
2. When the user opens a new tab in the background, and the new tab would show a subdirectory of a header-encrypted archive, then revert the tab to the root of the archive
3. When the user opens a new tab in the foreground, the user will immediately see the name in the header, so it should be allowed
4. Do not add closed tabs from header-encrypted archives to "Previously open tabs"

Are there still flaws in this suggestion?

Point 3 still seems flawed. Opening a new tab in the foreground is comparable to creating a new tab in the background, with the difference that the new tab becomes active and the original tab becomes the background tab. It is still possible for this to happen without the user's awareness, and possibly leaving behind a tab with a decrypted name in the tab header that is not visible.

[ghisler(Author)]

OK, seems like I can't make you happy with these suggestions.

I will try one last thing: When the user switches away from a tab with a header encrypted archive, I close that archive, and revert the tab to the directory containing the archive. This way it can only be open on the current tab, and no other tabs. The only other solution would be to not support header-encrypted archives at all.

[AntonyD]

The program supports the concept of filesystem plugins. In it, with ANY access to a file, a handler function from the plugin is called. So why not do something similar for Total itself? Let there be a special WFX plugin included in the mandatory distribution and installation - that would be responsible for certain sets of actions or inactions related to some files, under certain conditions that we define as necessary for the Total's functionality. For example, now when accessing an archive file we need to check what type of archive it is, and if it has a password, or the filenames\headers are encrypted — then this plugin will simply notify Total to either give me the password and show a prompt to the user about this situation, obtaining the password from them — or take an empty list of objects in it; anything else you still can't see. And that's it.

P.S. maybe WDX will be more suitable in this case. I don't know...
But the main thing is that this will always happen in one place — file analysis and the decision to process it. And it no longer matters where and in what location and how the user accesses this file, the list of open objects in it — first, Total's code will have to turn to the conflict resolver — to this plugin.

[ghisler(Author)]

Sorry, I don't see how this would help with the header-encrypted archive problem.

[white]

OK, seems like I can't make you happy with these suggestions.

You asked if there were still flaws in your suggestion and I answered you. It is of course not about making me happy.

I will try one last thing: When the user switches away from a tab with a header encrypted archive, I close that archive, and revert the tab to the directory containing the archive. This way it can only be open on the current tab, and no other tabs.

That seems secure.

The only other solution would be to not support header-encrypted archives at all.

Another solution could be to change point 3 of your solution to:
3. When the user opens a new tab in the foreground, revert the old tab to the root of the archive.

[ghisler(Author)]

3. When the user opens a new tab in the foreground, revert the old tab to the root of the archive.

I thought about that too, but it doesn't solve everything: For example, if the user opens a subdirectory in a header-encrypted archive and then adds a lot of regular directory tabs, the tab with the header-encrypted archive would scroll out of view. I only see two solutions here:
1. As suggested above, when the user switches away from a tab with a header encrypted archive, I close that archive, and revert the tab to the directory containing the archive.
or
2. When the user switches away from a tab with a header encrypted archive, I revert the tab to the root of that archive.

What do you think is less confusing for the user?

[AntonyD]

Sorry, I don't see how this would help with the header-encrypted archive problem.

I do not get it. But how in that case the overall processing of any files is done in flavour of any plugin?
If this case can't be used for such types of archive....

[white]

I only see two solutions here:
1. As suggested above, when the user switches away from a tab with a header encrypted archive, I close that archive, and revert the tab to the directory containing the archive.
or
2. When the user switches away from a tab with a header encrypted archive, I revert the tab to the root of that archive.

What do you think is less confusing for the user?

I think option 2 is less confusing. If a user switches to another tab and then returns, they will probably find it less confusing to return to the archive's root folder than to have to reopen the archive.

[AntonyD]

Hmm, but it seems to me that the opposite is true - if a person is thrown out of the archive, then he understands that something special is happening with the ARCHIVE. And if it just throws it out to the level of the first folders, then you can start to wonder if the Total is broken.

After all, for example, there is already such behavior now - I put a check mark on the tab that it is blocked, but it has the ability to change folders inside. And then I go deep into the folder hierarchy to level X. After that, I switch from this tab to others and do something necessary there.
But after that, when I return to this special tab, which can be said with a probability of 0.5, I will EITHER return to where I left this tab,
i.e. to a certain deep level X. OR I will have time to see the files from level X, but then I will be instantly forced to move
to the starting level - typical for the moment when the lock flag is set for this tab. And logically, there should be no such "jump back".
This is supposed to be a Total bug, and it needs to be fixed.
And if this starts happening to archives now, it's sad. A full exit from the archive looks more appropriate.

[ghisler(Author)]

2AntonyD
It may be less confusing, but it is more inconvenient to be thrown out of the archive than being just thrown out of the subdirectory.
Another idea would be to just show ********* or the archive name as the tab title for subdirectories of header-encrypted archives. But this would be confusing for drag&drop, which would then have to be forbidden for these tabs.

[ghisler(Author)]

In RC3, I have now implemented steps 1-4 from this post, plus reverting a tab to the archive root when leaving that tab. Please let me know if you still find problems with leaking names.

10.06.26 Fixed: When switching from a tab showing a subdirectory of a header-encrypted archive to a different tab, revert the location to the root of the archive to not leak the name of the subdirectory in the tab header (32/64)
09.06.26 Fixed: Removed the EncryptedNameCache option: Names in header-encrypted archives are now always cached only while an archive is open on one side (32/64)
09.06.26 Fixed: When trying to open a subdirectory of a header-encrypted archive in the background (e.g. Ctrl+Cursor up with "Ctrl+Up opens new tab in foreground" disabled), revert to the root of the archive (32/64)
09.06.26 Fixed: When opening a duplicate tab of a header-encrypted archive in the background (e.g. Ctrl+Shift+T), revert to the root of the archive (32/64)
09.06.26 Fixed: Do not add subdirectories from header-encrypted archives to recently closed tabs list, add the archive itself instead (32/64)