Is there an easy way to say "Search this folder and all its subfolders EXCEPT A, B and C" on the fly?
Thanks,
Roger
Testing Directory Opus prior to buying
Is there an easy way to say "Search this folder and all its subfolders EXCEPT A, B and C" on the fly?
Thanks,
Roger
Testing Directory Opus prior to buying
Use Opus Find (either the Find Window or the Find Utility Panel) in Advanced mode, and apply a filter.
Attached is a screen grab of a working filter. These are the files and folders used in this example:N:\Testing\DOpus 8\Test
| File D.txt
|
+---Folder A
| | File A.txt
| |
| \---Subfolder A
| Subfile A.txt
|
+---Folder B
| | File B.txt
| |
| \---Subfolder B
| Subfile B.txt
|
\---Folder C
| File C.txt
|
\---Subfolder C
Subfile C.txt
With the filter below, I am searching for all *.txt files that are not under Folder A, or under Folder C.
NOTE: Pay special attention to double negatives when using a Filter Subclause to filter something out (as opposed to trying to filter something in). Notice in the working example below that I specify No Match at the subclause level, but all of the possibilities within the subclause (\Folder A and \Folder C) are set to Match. If all of these were set to no match, the double negative would logically resolve to a Match, which would not be the desired output.
As the Find Dialog below is structured, the logic is this:
In the current folder its subfolders, and any .zip files contain therein, search for all objects whose name ends in .txt, except below Folder A, or below Folder C.
I haven't had opportunity to go through the documentation -- there's so much of it, and what I saw on search overwhelmed me. With this one clear example, now I get how the filter works.
Thanks!
Roger
Glad to help. Definitely take the time to read the documentation, at least the feature sections that you find yourself using often or most interested in using. Opus has more power under-the hood than you will be able to get a handle on all at once.
@Any of the Resource Centre Moderators:
Could someone please copy my post above as a FAQ? It should serve as a fairly clear example of how to: filter subfolders (out in this case) and use a subclause. Many Filtering questions come up, and this example should help many new users get a handle on how to use them.
I'll make this into a FAQ (been thinking about doing a tutorial on making filters) but before I do, any thoughts on a couple of things?
Choice between potentially confusing people and showing them an additional, useful concept.
In this case you need a slightly more complex location filter, but unfortunately the "correct" way of doing it may look like a load of strange characters to the uninitiated:
*\Folder A(|*)
Choice between being "correct" (which often won't matter) and keeping things simple.
...
Maybe the best thing would be to build up from a simple example, then show sub-clauses and then show the "correct" location wildcard, so people only have to understand one thing at a time, built upon what they just learnt.
Or that kind of thing could be left to a tutorial and the FAQ just says "here's how to filter by location and if you want to learn more see the tutorial (once someone makes one)".
If you or anyone else has suggested scenarios for a filtering tutorial let me know. I'd like to make another video tutorial (with sound this time) and I think filters (for both find and copying/deleting/sync/etc.) would be a good subject to cover, but it won't happen for several weeks at least as I've got loads of plugin stuff to do plus that pesky day job.
Yeah, I intentionally put in the subclause, so I could talk about the double negative thing. (Filters are based on logic which many Opus users may not understand; in fact, people without a coding or high-track math or logic background might get lost with ANDs, NOTs, ORs, etc.)
[quote]2. Your filter will also exclude folders which start with the names of the ones you want to exclude. For example, if you want to exclude "Folder A" but include "Folder A2[/quote] Guilty!
I did realize my wildcard syntax was going to present a possible issue. However, like you said, it is usually unlikely to happen. I was trying not to have him drink from a fire hose and was willing to help out further if that issue came up.
I prefer this approach. The new comers are better served because it takes them from the simple to more challenging and they can build upon things. It also showcases the raw power of Opus better. This gentleman is trying the app before buying it. So the trick is to come up with a usable example that demonstrates a lot, but at a digestible pace.
Start with a very simple filter example (like the search for .txt files, or more than one file type). Then build up to a slightly more complex example (show a few uniquely named folders and exclude a couple of them, perhaps not with generic names like we have been using here). Then go after a couple of really challenging question (a search of the forums should net some good examples).
In fact, I posted a screengrab of a rather complex (yet very useful) filter in this post a while back:
This filter does require subclauses. I use it every time I Synchronize (nowadays without so much as a second thought--in fact it is always selected by default when I open the Sync Utility panel.)
I think the filter in that thread could be used in a case study example along with the one we've been discussing in this thread. The one in that thread could be used as a Filter clause of the one in this thread. (This would of course be at the advanced end of the discussion.) But it would show the reusability and power of Opus filters.
Some may argue that such an example is too complex for new users. And if discussed all at once, I would completely agree with them. However, I would argue that its complexity makes it a better, more "real life", case study to discuss and mentor from. Breaking down the case study piece-by-piece allows the users to pick up several topics and mentally link them all together.
I would say that any discussion regarding a filter needs to touch on (in a straw-man suggested order):
[ul][li] A breakdown of wildcards that can be used inside a filter (like those we have used here in this thread, not regular expression...yet)[/li]
[li] How to create a filter on the fly (using just a few simple elements)[/li]
[li] How to save a filter for reuse.[/li]
[li] How to apply a saved filter (like in Sync)[/li]
[li] How to make a copy of a filter (so the case study can be continued without the user losing the completed simple example)[/li]
[li] How to edit a filter (edit the copy to add the other elements as user understanding progresses)[/li]
[li] Display the effects of the Synchronize|Find|etc with and without the filter.[/li]
[li] subclause structure[/li]
[li] filtering something out as well as filtering something in.[/li]
[li] filtering certain: drives, folders, and paths[/li]
[li] How to include a filter within another filter.[/li][/ul]
NOTE: Regarding the filter at the link above, Jon and Greg have since excluded the System Volume Information and Recycler folders from Sync operations; however, as I reported in BBT issue report #KA00016, Recycled (FAT32) is not excluded. Also the filter linked above does go beyond these two files.
I encourage you to proceed as you suggest here -- examples and tutorials are especially helpful and I really was surprised not to see such material in the FAQ already.
But being able to proceed by following simple examples that get progressively more complex (as my needs might) works for me.
I wanted to just toss in this note:
When I look at the example in the screen shot, I want to read it this way:
Include all the files that (such and such)
BUT exclude any that are (located in this folder OR this other folder)
Then I can translate to "match" and "no match".
Whether the first combining word is AND, BUT, or EXCEPT, I'm not certain which is the clearest -- I can make sense of all of them.
Thanks again for the help.
Roger
As I look at this example, I'm wondering whether it
A) excludes files in those folders from the results,
or
entirely excludes those folders from the search.
I'm interested in the latter, so that the search doesn't bother with folders where I know the file will not be found. Does "location" make B happen?
Thanks,
Roger
You should use the Subfolder clause, rather than Location, for doing that.
Subfolder -> No Match -> Name
Be careful with Subfolder since it is applied recursively. It's great for filtering stuff out (as is the case here) but think carefuly before you use it to filter stuff in (since whatever filter you use has to apply to all levels in the directory structure).