I have a network backup disk H: with dozens of folders named H:*\SpecificFolderName. Each * is a different month of backup. I would like to search all backups of the ...\SpecificFolderName folders for a file name (also with wildcards). It takes WAY too long to search the entire network disk. This is not a good candidate for the find filters in Advanced Find, since there are so many backup folders and they're changing all the time. Using a wildcard path like I show here in the "Find files and folders in:" textbox doesn't work, unfortunately. Is there a way to do this?
Maybe there's a more simple way but this is what came to mind.
The first clauses means only files in the desired places are matched. i.e. Only files directly below F:\Test\XXX\SpecificFolderName, for any folder called XXX. If you use a wildcard instead of a regexp then there isn't a way to prevent additional matches, like F:\Test\X\Y\Z\SpecificFolderName. The regexp ensures there's no \ in whatever matches between Test and SpecificFolderName.
(Actually, you probably could get away with a simple wildcard for the first clause because later clauses should prevent other matches. It doesn't hurt to be explicit, though.)
The second clause simply matches want* so that I get the wanted.txt files but not the otherfile.txt files.
The first and second clauses on their own are enough to get the correct results. However, Opus will still search the entire drive, which is what you're trying to avoid. To speed things up there is a sub-folder clause.
Sub-folder clauses are special. They can stop the find operation from entering a folder (and all of its sub-folders) at all.
The sub-folder clause has three sub-clauses which allow F:, the F:\test and F:\test* (where * has no \ in it) but nothing else. So it allows the find operation to enter folders which are below F:, F:\test or F:\test\XXX\
I made things a bit more complicated by putting my test files below F:\Test. In your case, since your folders are directly below H:\ you'd only have two sub-clauses, H:\ and (regexp) H:\[^]+
Sorry not to have gotten back earlier, but I forgot about this post and now I need the wildcard-directory search again and can't make it work. I tried your suggestion above and various other regexps. I'm looking for a file in any folder H:*\D\Exality\Sonarwire\2.5 Tool\P-PLA, where * is a number of different archives. The attached screen shot is my latest attempt, where I use .* in the regexp to represent the various archive names. The search either does nothing or begins searching the entire H: drive, depending on whether I include a subfolder clause which ORs H: like your example. I've tried a simple test of looking only for a known file in H:*\D\Exality, too, with the same results.
I think the problem is that your final clause is at the top level; instead it should be inside of the Subfolder clause.
Have a look at my example screenshot and you can see the clauses after Subfolder are all indented, because they're children of the Subfolder clause. In your screenshot the filter after Subfolder is not indented and the Subfolder part isn't doing anything (since it has no children).
[quote="planetthoughtful"]Hmmm. The following seems to work:
Two clauses.
First clause: Location Match (using regular expression) H:\.\SpecificFolderName\
(note the trailing \*)
Second clause: And Name Match (using wildcards [or not, depending]) warp.rc
Hope this helps,
pt[/quote]
Without a Subfolder clause the search will take much longer because it will look inside every folder (and every sub-folder, etc.) and then check that the files match the path. The Subfolder clause in my example ensures that that the path is checked before a directory is entered, so that locations which cannot contain any matches are ignored.
The Subfolder clause doesn't change which results are returned, so both examples may give the same end results, but it will avoid a lot of disk access that isn't needed.
I'm obviously misunderstanding something. Isn't that what the "Find in" value limits the search to - a series of subfolders beneath a particular directory?
As a simplified example, say you are searching in C:\Windows for files you know are in a directory that starts with the name Sys. (System, System32, SystemWOW64, etc., depending on the machine.) You wouldn't want to search the other 60 directories in the Windows directory and using a Subfolder clause lets you prevent that from happening.
Still doesn't work when I make the subfolders clauses subordinate. That's good to know though!
The Dopus help for regexp syntax says that * matches the character to the left, which would say that .* would match 0 or more of any char, but my feeble Unix brain seems to remember the syntax is *. for that, and planetthoughtful here seems to agree. Is there an error in the regexp help?
Also, I don't understand why the subfolders clauses would include F:, F:\test, OR the regexp (from your example). Wouldn't that just mean to search all subfolders? Doing this here doesn't seem to help either. It doesn't search at all.
It won't search all subfolders because the clauses don't have wildcards in them. They are telling Opus that it should only search inside a folder if it is F:, F:\test or something that matches the regexp (which is all folders directly below F:\test, but none of their sub-folders).
Note that the subfolder clauses are not F:*, F:\test*, etc. They are F:, F:\test, etc.
I'm sorry, I just can't seem to get this. I'm trying to find all occurrences of the file network.bu here, in any folder H:...\D\Exality. I know there are many. When I set up the search as shown, the output window opens but no search takes place. I only want to look in folders H:...\D\Exality, so it seems like only one subfolder child clause as shown here should do it. What am I doing wrong in this example?
You need three more subfolder clauses which match:
H:
H:\[^]+ (regexp)
H:\[^]+\D (regexp)
and you should change the existing subfolder clause to
H:\[^]+\D\Exality (regexp)
unless the .* in your example is intended to allow more than one folder level between the H:\ and the D levels. (If there is supposed to be more than one level let me know as my examples will be wrong in that case.)
As your search is at the moment Opus won't search anything because you start in H:\ but only go into folders whose location (i.e. parent folders) match H:\.*\D\Exality.
The location of the folders directly below H:\ is -- of course -- "H:" and "H:" does not match the regular expression "H:\.*\D\Exality" so the search will stop right there.
I think I understand now, you need to "lead" the search through each of the paths above the specific path you intend, thus the OR. When I set up the search as shown below though, DOpus starts looking through everything on H: so I'm still missing something.
BTW, there is only one folder level between the root and the D folder, so I'm using the regexp you suggest.
With the current query, Opus will scan everything inside of H:\ H:* (first level) and H:**, and H:*\D\Exality*
I've just realised that the search currently goes inside the sub-folders of H:*\D\Exality unnecessarily, so we can remove that part. (It's looking for a file in the Exality directory, so there's no need to scan the sub-directories of Exality.)
The H:** level is also searched unnecessarily. If we turn one of the Subfolder-location clauses into a sub-clause which matches Location and Name then we can restrict things further and avoid going inside all of the H:** directories which are not called D.
Similarly, we can do the same for the H:*\D* level, by only going inside folders called Exality there.
That just leaves the H:* level where we are still scanning inside all folders (but not their sub-folders) even though we only really want to scan inside the folders which contain a D directory. I don't think there's any way around that at the moment. (I guess you could ask GPSoft to add a Contains clause for use with Subfolder, so that you could say "only go inside folders which themselves contain a child folder called D". That seems quite an esoteric option though; this might be the only time it gets used. )
So, here's what I think is the best query. It's got quite complex and hard to think about, with all the recursion and sub-clauses involved.
Note: I haven't tested this. Apologies if there are mistakes!
Here's another version of the picture above, with the different clauses colour-coded. I hope it makes it easier to see exactly what's going on. (Maybe it's just more confusing. )
)
)