Mo-Search is a secure, powerful and easy to use Indexed Desktop Search that puts you in control of your data. By quickly and easily locating files and data, your time once again becomes your own.
Upon installation your computer is indexed (much like Google + Bing index the web). Once complete, AutoIndexer maintains your Index by transparently incorporating new files, and updating details on modified files. This search Index is what sets Mo-Search apart. Not only is blazing search speed achieved within the content of a million+ files, but results are ranked by relevance using a weighted average of factors including Hits, HitsDensity, ModifiedFrequency and ModifiedDate. Once initial indexing has completed, Mo-Search makes searching easy: Just start typing and AutoSearch shows results as you type. Optionally - Search filters provide finer grained filtering by Filename, Path, Modified Date, and Search Domain. Wildcards may also be used to broaden a search. And the more you search, the more your index is optimized searching gets faster! Hashtag Search Operators: Such as #NoDups (hide duplicate files in your results) provide additional seamless capabilities. To explore possible hash operators, in Advanced search mode simply type # into the search Text filter and Autocomplete will show the entire list. The Results list automatically Sorts by relevance, but can also Sort by filename, location (path), Size, Modified Date, and further Filter by File Type. The FileViewer provides quick navigation of matching files, plus a host of File tools: Analysis, Checksum, Email, Export, Print, Word Counts, Properties, IndexWords, and more. A suite of other tools are also included: File Duplicates (cleanup duplicate files), File Types (what's using the most space?), File Analyzer (Line/Frequency Analysis - great for Log files), Whois internet lookup, and File Index analysis.
Yes - 40 day timeout
- Feature>Indexer+Search: Added search-able characters: Ä,Ö,Ü,ä,ö,ü (thanks Ferdinand)
- Feature>Indexer+Search: Added default text search extension: .json
- Feature>Search: Improved Text AutoComplete word matching (more relevent AutoComplete matches)
- Feature>FileViewer: Auto-jump into Find mode when a user highlights text, for an experience more similar to Notepad++ (e.g. Selected text is instantly highlighted throughout the file)
- Feature>FileViewer: Allow the user to highlight-text to select (similar to Notepad++)
- Feature>FileViewer: Show relative match(es) position (for both Ctrl+F and TextSearch modes) via area adjacent to Vertical scroll bar (similar to Chrome)
- Feature>Indexer: Prompt to re-use custom Paths or OmitFolders upon full re-installation
- Feature>Config: When Paths (SettingPath.cus) or Omit folders (SettingOmit.cus) have changed, serialize to install folder (to streamline full index rebuild/install)
- Optimization>Indexer: Improved performance when deleting and adding directories having similar files. Previously slow (delete, promote, delete) cycles may have occurred in series. Now we promote to the latest ID to decrease deduplication promote/delete ch
- Optimization>Combos: Don't create Cue font, if Cue text is not set for the control (e.g. most combos)
- Optimization: Smaller installer size due to coalescing dll-based unzip code directly into mobase.dll/CDocxMgr, which results in removal of a big chunk of unneeded logic
- Bug>All When indexing/reindexing/searching, gradual Database corruption led to cryptic database errors obscuring root cause. Fix is to synchronize Index writes across all threads + processes (6.x issue)
- Bug>Indexer: Possible buffer overrun resulting in crash for file types: docx, jar, odp, odt, pages zip (all versions, longstanding, very rare: seen once)
- Bug>Indexer: Could not index a child folder (e.g. X:\photos) if the root folder (X:\) wasn't included (longstanding, multiple versions)
- Bug>Indexer: Error when renaming a folder in Windows: Value violated the integrity constraints for a column or table. (longstanding, rare)
- Bug>Indexer: In install, could not set a single path if was not a root folder such as X:\photo (longstanding)
- Bug>Fileviewer: Wrong color (e.g. yellow) was sometimes used to highlight matching/selected text (e.g. blue)
- Bug>Fileviewer: Multiple lines of matched text incorrectly rendered on 1 line. Now each line of matching/selected text properly renders on the correct line (6.x issue)
- Bug>FileViewer: When only one match is found, show [No Other Matches] instead of [Text Not Found] in yellow footer
- Bug>Fileviewer: Wrong text color used in buttons upon mouse-over. For example, integrated find [Options] and [x] buttons text color now remains black (Were turning white, and largely illegible - fix in MDialog::_CreateButton)
- Bug>Search: Multiple consecutive spaces or wordbreak characters resulted in AutoComplete not showing valid words (6.x issue)
- Bug>Search: Error when attempting to add Key Word already present in index (6.x issue)
- Bug>Database: Removed prepared query support to reduce occurrences of rare database errors (6.x issue)
- Bug>Database: Add query lock/release mutex to reduce occurrence of rare database errors (6.x issue)
- Bug>Database: Error reported in log files: SUM(SizeKB), which is actually not an error
- Bug>Patch: Don't show an error when including new TextIndex file type(s), if the file type was already included by the user
- Etc>Search: When trial period expires, auto-show license dialog at most every 2 seconds when performing an auto search (before we were showing every keystroke)
- Etc>Search: Slightly tweaked ranking, to be a bit more biased to Hits and HitsDensity
- Etc>Diag: In log, include database current internal-version when logging [Patch_1 Start]
- Cleanup>Etc: more dead code removal and smaller optimization
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