Searching archives recursively

Here you can propose new features, make suggestions etc.

Moderators: white, Hacker, petermad, Stefan2

__Vano
Junior Member
Junior Member
Posts: 9
Joined: 2006-12-13, 00:52 UTC

Post by *__Vano »

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.
User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 48012
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Post by *ghisler(Author) »

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.
Author of Total Commander
https://www.ghisler.com
__Vano
Junior Member
Junior Member
Posts: 9
Joined: 2006-12-13, 00:52 UTC

Post by *__Vano »

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.
Post Reply