Yes, I did see that Rob, but I just wanted to be sure that it is not just finding subfolders that are empty, but both the parent and child folders that are.

Awesome!  I suggest that you go an check to see if the search results are in line with what you were expecting!  I just tested this out on my side and found some interesting results, so if this search syntax doesn't return what you're expecting, just let me know where the results don't align with what you were expecting and we'll see what other options are available, if necessary.

I am getting the correct results, but it takes a very long time. I applied the search on 6 folders. One of the folders was empty and I created another empty folder with 2 empty subfolders. It took 2 hours to finish.

Hmmm that doesn't seem very useful.  The search being run is certainly resource intensive, but not to the point where it should take 2 hours.

When you say that you applied the search on 6 folders, do you mean that there are only 6 folders in the entire repository, or only 6 folders at the root level?  No matter the circumstances, of course 2 hours is far too long; I'm just looking for additional information to help me troubleshoot.

Can you confirm that other searches run in a more reasonable amount of time?

The repository is huge. I created the 6 folders as test folders, I beleieve at the root level.

Department - > Clerk - > Testing - > Then the 6 folders

It is only when I use advaced search do I see it taking well beyond the average time (25 minutes max) for any of the other searches.

Just finished re-running the test, but this time with 59 parent folders and multiple subfodlers within. The search did not generate empty folders. Back to square one.

I think it's time to take a step back and figure out exactly what's happening here.

1) Why do you need to run this search?  Is this a one time thing to clean up the repository or will this search be run regularly?

2) Why can you not use Workflow?

3) It sounded like you tested the search and it returned results in line with what you were expecting originally.  Using the same syntax with more folders changed the logic of the search?

Thank you so much for all your help Rob!

1) Clean up the repository - I plan to refine my "empty folders" results by date as well.

2) There is only one person in my organization that has access to workflows. They do not plan to allow anyone else...

3) Yes, not sure why it changed with the addition of more folders.

I can think of two possible reasons why the results did not match your expectations:

1) If you are looking to return only folders that do not have any contents (no documents, folders, or shortcuts), you need to specify the type for LF:ChildName,  since ChildName defaults to only documents. This means that folders which contain no documents but do contain subfolders would be returned from your search.

To return folders with no contents:

{LF:Name="*", Type="F"} - {LF:ChildName="*", Type="DFS"}

2) Some security settings may interfere with the results. I was seeing folder that had contents be returned when I only had browse rights to those folders.

I'll run this now and see what I get.

Thank you Brianna!

To add to Brianna's points, you might want to try modifying the security for the user who's running the search.  In particular, you'll want to give that user the Bypass Browse right in the Admin Console.  

The reason I expect this to help is because when running searches, the search logic must remember to not return entries that the user doesn't have access to.  This "security evaluation" increases the resources necessary to run the search, and in turn, will make the search take longer.  Searching with a user who has Bypass Browse will remove the need for the Client to evaluate security, and should yield faster results.

I'm wondering if we can get more predictable results when specifying the "Type" as Brianna pointed out above.  In case you're wondering, D, F, and S, in the syntax above are representing Documents, Folders, and Shortcuts (the three entry types in Laserfiche).  I'm not positive how specifying the entry type in the search affects the time required to run, but hopefully when combined with the Bypass Browse we can get more reasonable search times.

Brianna, I get an error when I use the syntax you posted above. I am running it once more and I will post my findings.

What specifically is the error you get? When I copy and paste the syntax I posted and run the search, I do not have any issues.