Total Commander

I don't see a problem with an option "search recursive archives (slow!)".

Apart from .tar.(gz|xz|bzip2|lzma), this also stands for containter files like .iso, .wim, the aforementioned .(j|w|e)ar - for which it is not an anti-pattern and commonplace to contain embedded archives.

A workaround specifically for .tar's would be to stop handling them as 2-level archives. Contemporary TAR libraries can handle the compression transparently, and seeing an unpacked .tar is very rarely needed (only a few times in my 15+yr practice as an IT Pro). In fact, handling them as such is currently a nuisance due to the latter.

The problem is that you couldn't do anything with the results: For example, F3 wouldn't work because the temporary archive would already be gone.

This isn't really a showstopper: since search results are full paths, complete with archives, it can be unpacked again.

We basically need to find a compromise between fast operations and cluttering the disk. Let's see what the use cases are...

• I needed to find all Perl modules (packed as .tar.gz) that have C++ code in them. So, export the list then process it with scripts of whatnot.
• From time to time, I need to find a specific file in a Windows distribution. Naturally, I don't know how many archives down it is. Here, it's locale and unpack something specific.
• ado needed to locate a specific .jar in a .ear. He didn't specify what he needed to do with it. I guess it may be to check if it's actually there (if not, the app has been built incorrectly), or see which .war it is in, or check something about it more closely (like if a specific class is there). This way, they would open the specific archive from search results in the other panel or whatever.

So, the use case for this appears to be to 1)locate something in a package with unknown structure and 2)possibly inspect a few of the located items. For this, unpacking again doesn't seem much of an overhead compared to the time the search saves.