Mo-Search is a secure, powerful and easy to use Desktop Search designed to get control of your computer's data. By quickly and easily locating files and lost data, your time once again becomes your own.
Mo-Search makes searching easy: Just enter a word (or phrase) and press search. Optionally specify any combination of Path and Filename/extension (or Search Domain). Wildcards can also be used in any of these fields. The Results list automatically Sorts by relevance, but can also Sort by name, location (path), size, modified date, and further Filter by file type. The FileViewer provides quick navigation of matching files, as well as other tools: Email (file attachment or excerpt), Print, Word Counts, File Properties, File Index, and more. The AutoIndexer continually updates your index using industry standard iFilter, plus a host of indexers. A suite of other tools are also included: Duplicate files detection and cleanup, File type analysis, Whois internet lookup, and File index analysis.
Yes - 40 day timeout
- Optimization: Faster searching (big cache-build speed increase for multiple search terms, by reducing number of queries)
- Optimization: Increased compiler optimizations in targeted areas (pragma optimize)
- Optimization: Faster filename indexing (removed redundant word weighting code)
- Bug: Incorrect word UseCount: inaccurate search ranking for deDup'd files (6.0.0 issue)
- Bug: Crash during initial index build, when indexing Avast files (added new Omit folder: Avast)
- Bug: AutoComplete may not work if SearchSound was disabled (6.0.0 issue)
- Bug: Enable ExamineIndex dialog on indexed files within Explore mode (6.0.0 issue)
- Cleanup: Only play TimerDebug beeps when EnableDiagnostics is enabled (6.0.0 issue)
- Cleanup: Don't show Cancel button when ExtendingSearch cache because the operation cannot be canceled - currently (6.0.0 issue)
Reviewing 6.0.0 Alpha (Oct 7, 2015)
I'm biased to Mo-Search for my needs. But I agree Archivarius is a good alternative that supports a very impressive number of file formats!!!
Unrelated - I want to comment on Mo-Search Indexing + Searching speed, and its evolution.
Mo-Search 3.x had a JET backend, and with 3 years of revisions + optimization it was slow. It worked fine if you had a limited amount of files to index/search, but otherwise not good. Really not good at all. Over time, this became a problem and led to...
Mo-Search 4.x switched the backend (database format) to SQLCE 3.5, which worked better. It scaled a lot better than 3.x, and improved slightly during 18 months of iterations, but still left a lot to be desired for larger amounts of files.
Mo-Search 5.x switched (again) to SQLCE 4.0. Also 5.x received a major architectural change of horizontal partitions (FullText index spread over 27 tables, instead of 1). Over the course of 3 years performance improved some more. But these iterations (up to 5.6.2) still hit a performance bottleneck for really large sets of files (including my 1+ million file test environment).
Mo-Search 6.x internally started as 5.6.3 (minor tweaks/fixes), but as development went along (and more feedback received) bigger changes/ improvements led to internal version 5.7 (also never released) mostly geared towards scalability. But as focus moved further to higher scale, and breaking the 4GB backend index barrier, the following major architectural changes coalesced. Items 1 and 2 improved performance; 3 and 4 were somewhat built on the new performance.
1) DataDeduplication - Can really improve indexing scalability in environments where duplicate files exist, such as software development with multiple branches. This works by de-duplicating index data (in RAM) during indexing, to reduce the amount of data written into the index. Then upon searching, very small/specific data subsets are re-duplicated into horizontally partitioned cache to facilitate proper ranking, combined filters, all the things the search UI provides. (Initially the goal was to perform search re-duplication purely in RAM, but complexity started to spiral - may possibly revisit in 7.x)
2) Database Sharding – Previously we’ve always had a single backend database file (3.x, 4.x, 5.x). Now it’s been split into 3, each holding different segments of the indexed data (and each of those horizontally partitioned). This allows us to break the 4GB index barrier (previous versions started performing poorly when the backend grew into the high 3GB range), and also improves performance regardless.
3) AutoSearch - In Simple Search mode (Just Text search box is visible), as you type... the results auto-populates (as does Google, and other tools including the very popular Locate32). This feature has been on the back burner for years, so its about time. Just a first rev, but still about time.
4) AutoComplete - in Advanced Search mode (Text search box, Filename search box, Path search box, etc, all visible), as you type... all relevant indexed data is used to AutoComplete. Previously only recent search terms were used to AutoComplete, and at most 400 recent terms. Now *ALL* indexed words, filenames, paths, are used in AutoComplete for the corresponding search box. If you have 1million files, that list is used to AutoComplete within the Filename search box. This feels a lot more productive to me, but... its a big change. (Like everything else - feedback is requested and hugely appreciated!!)
Internally, different versions of Mo-Search are re-tested to identify and track regressions (including indexing + searching performance). For a quick indexing performance comparison ran today on my 2011 Laptop (Intel SSD 320 + Core i7-2760). Here are the full index build durations:
4.0.13: 44 minutes (383k files, 1.52GB index, 132million words)
5.6.2: 21 minutes (383k files, 1.08GB index)
6.0.1: 12minutes (383k files, 681MB index)
And as the corpus size (volume of files) increases, older versions slow further at an increasing rate.
Your desktop/workstation/laptop and corpus (volume of files) will differ, and likely has different performance. But the points I'm trying to make: Performance matters. Usability matters. And so does constant work to keep moving forward.
Also, great comparative feedback on meauxsoft/Archivarius sites. Archivarius really makes meauxsoft.com look quite sad :-( I need to work on that.
Reviewing 4.0.16 (Apr 30, 2012)
Mo-Search *will* take longer to build the initial index because it indexes: file names AND file content too (Locate32 does NOT index file content). Once this initial index is built (33 minutes for me with 163,000 files/80 million words), the index is auto updated.
Locate32 works fine but doesn't search inside files, which is what I need daily.
@NyaR – how many Files & Words were indexed in those two hours? I bet a lot.
Reviewing 4.0.16 (Apr 30, 2012)
Thanks for making the app but it is unusable to me... nearly an hour to scan two terabytes of drives? Locate32 does this in minutes.
Reviewing 4.0.14 (Feb 22, 2012)
Mo-Search saved my life - or at least hours and hours of work. I've been doing a lot of revision of a lengthy academic paper and in cutting and pasting footnotes, I lost some of my original source documentation. Fortunately, I had saved a pre-revision copy and, with appropriate word choices, I was able to use Mo-Search to find the unedited footnotes in the unrevised manuscript to get me straightened out again in the revision document. I have lots and lots of Word files on my computer and I've found this program to be a tremendous help. You have to noodle around in it a bit to find all the features, but it's worth it. One hint I've found is that when you get ready to open a Word document (either file or folder), you can click on Mo-Search from that screen and search just that file or folder. It really is a terrific program. Thank you to the software writer for making it available.
No comments yet