I think I found a bug:
If I select a bunch of zip files inside a .7z file, and click on "extract to destination," the file contents of each .zip file are NOT extracted, but the .zip files are copied to the destination instead.
In other words, when acting on files inside archives, "copy" and "extract to destination" do the same.
That's what "extract to destination" does with any types of selected files within archives. It just extracts the selected files to the destination. The files being archives-in-archives isn't treated specially, and direct extraction of the contents of archives-within-archives is not supported.
They have to be extracted, then their contents can be extracted.
I understand. It is just my same old complaint about archives in new clothing I guess.
I would argue it would be so much more helpful if that extraction was automatic. It is automatic in a lot of other operations. For example, if I view a photo inside a .zip file, I do not manually have to extract it first. The extraction is automatic. In my mind, there is no conceptual difference between the operation "view image" or "extract to destination." If one operation automatically extracts and then acts on the extracted file, ALL of them should. It is just a weird coincidence that the "extract to destination" operation has to do with extraction itself. But we could be talking about an operation such as "edit in notepad" instead. Why are they treated on unequal footing?
In other words, it seems so inconsistent: If I use "extract to destination" on a regular .7z file that is selected, it extracts the contents to the destination. If I use extract on a .7z file inside a .zip file, it should also extract its contents to the destination, e.g. extract the .zip file to a temp folder (or better: ram) and then extract the contents of the .7z file to the destination. I can only imagine the weird special-case handling that must go on internally, e.g. for some operations DirectoryOpus must have conditionals such as "if file is part of an archive, do this, if not, do that" internally, but for others they are "if file is part of an archive, automatically extract, then do this, if not, do that"
In yet other words, I shouldn't have to look at my path bar to check whether I am currently looking inside an archive or a regular dir to find out what the Opus actions will do.
EDIT: I think it might just all be a side-effect of this obsession to do every operation via a keyword to an existing Opus command, e.g. instead of an extract operation, we have a "copy /extract" command. I think this creates inconsistencies. Because if I would make my own button using unzip.exe to extract, for sure it should behave consistently and do the automatic extraction. After all, then it is just an external command. I already now my external Notepad++ command automatically extracts before opening .txt files inside archive and I didn't have to do anything special. Now I am in a pickle, because my own buttons that call external unzip programs behave fundamentally different then the internal extraction commands. That means I will have to mark them all with some symbol or * or something to make sure I remember.
The way it behaves is already consistent. If you are inside an archive, select a file, and click Extract to Destination, it will extract that file from the archive you are in and write that file to the destination.
You're asking for it to be made inconsistent when an archive-in-an-archive is selected.
(Is there a reason for having archives inside archives, by the way? If it is so everything is compressed as a single unit, using the 7z format and solid mode will do that without needing nested archives, for example.)
Hmm, I guess it depends on the definition of consistent. I agree if you read "extract to destination" as the verbal instruction and think about what users expect this would mean in each context, it is consistent.
However, I really don't like that it is the same as copy when I am inside an archive, but it acts different from copy when I am outside an archive, if an archive is selected.
I give up. The reason for archives inside archives is the internet, that's all. I don't know why the internet insists on putting archives into archives into archives. But that's what it does. And the worst thing is that brilliant coders do it who should know better.