docfetcher.sourceforge.io

Indexing improves file management by pre-building a map of which words appear in which files, so a desktop search tool can answer content queries in milliseconds instead of scanning every file on every search. In DocFetcher, an open-source desktop search application for Windows, Linux, and macOS, you create an index once per folder you want to search. After that, searches run against the index rather than the raw files, and updating the index after files change typically takes only a couple of seconds.

Why scanning files directly doesn't scale

Without an index, finding a document by its contents means opening files one by one and checking for your search terms. That works for a handful of files but breaks down across a whole drive: the cost grows with the total number and size of files, and every new search repeats the same work.

An index changes the economics. DocFetcher builds a lookup structure that records which files contain a particular set of words, so a query resolves in the order of milliseconds regardless of how many files sit behind it. The trade-off is upfront work: building the index takes time, but only once per folder.

How indexing works in DocFetcher

DocFetcher requires you to create indexes for the folders you want to search — it does not search arbitrary locations without one. The workflow is:

1. Choose a folder you want to make searchable.
2. Create an index for it through DocFetcher's index-creation dialog.
3. Run the indexing process, which reads the files and records their contents.
4. Search normally afterward; queries hit the index, not the files.

The indexing step can take a while depending on how many files you include and how large they are. A useful planning figure from the project's own documentation is roughly 200 files per minute. So a folder of 2,000 documents is on the order of ten minutes of indexing — a one-time cost, not a per-search cost.

Creation is slow, updates are fast

The important asymmetry: creating an index takes time, but updating it after the folder's contents change is much faster — usually just a couple of seconds. This is what makes indexing practical for active folders. You pay the full price once, then pay a small price each time you add, edit, or remove files.

What you can do once files are indexed

Indexing is the enabler; the search interface is where it pays off. In DocFetcher's main window, queries go into a text field, results appear in a result pane, and a preview pane shows a text-only view of the selected file with all matches highlighted in yellow.

You can narrow results along three independent dimensions:

Combining these turns a broad content query into a short, relevant list — for example, a term plus a file-type filter plus a location filter to isolate one project folder.

Portable indexes for file management on the move

DocFetcher offers portable versions for Windows, Linux, and macOS. These let you build a portable document repository: a fully indexed, fully searchable collection of your documents that you can move freely. Practical uses include carrying it on a USB drive, packaging it for archival, placing it inside an encrypted volume, or synchronizing it between computers through a cloud drive.

This is the clearest illustration of why indexing matters for file management: the expensive part (building the index) travels with the documents, so search stays fast wherever the repository goes.

When indexing is worth it — and when it isn't

Indexing pays off when:

• You repeatedly search the contents of many files, not just filenames.
• The folder is large enough that manual scanning is impractical.
• The folder changes often enough that fast updates matter (they do — updates are seconds, not minutes).

It may not be worth it when:

• You only need to search a few files occasionally.
• The folder changes so rarely that a one-time index still sits unused.
• You need multi-user access or a web interface — the project points to DocFetcher Server, its commercial variant, for multi-user support, and to DocFetcher Pro for additional features beyond the open-source edition.

For a single user searching local documents on one machine, the open-source DocFetcher covers the core case: index once, search in milliseconds, update in seconds.

Apache Lucene is a Java library for full-text search, not an application you install and run on its own. It gives developers the core machinery for indexing text and retrieving documents that match a query. Desktop search tools such as DocFetcher build on it: DocFetcher is an open-source desktop search application that lets you search the contents of files on your computer, and it requires you to create indexes for the folders you want to search. If you want to search your own files, you use a ready-made application like DocFetcher; if you want to add search to your own software, you work with Lucene directly.

What Lucene actually is

Lucene is a Java-based full-text search library. It is not a standalone program, a server, or a database. Its job is to take text, organize it into a structure that supports fast lookup, and then answer queries against that structure.

Because it is a library, it does not decide what gets indexed or how results are presented. Those decisions belong to the application built on top of it. DocFetcher is one such application: it handles the user interface, file discovery, and preview, while the underlying search speed comes from the indexing approach Lucene popularized.

How indexing enables fast search

The central idea is the inverted index. Instead of scanning every file each time you search, the system builds a map from words to the documents that contain them. A query then becomes a lookup rather than a full scan.

DocFetcher describes this in practical terms: an index allows it to find out very quickly — in the order of milliseconds — which files contain a particular set of words, thereby vastly speeding up searches.

Building that index takes time. DocFetcher's own rule of thumb is about 200 files per minute, depending on the number and sizes of the files. The trade-off is that indexing is done once per folder, and updating an index after the folder's contents change is much faster than creating it — usually only a couple of seconds.

The pipeline in plain terms

1. Collect text — the application gathers the text to be searched (for DocFetcher, the contents of files in chosen folders).
2. Analyze — text is broken into terms. This is where tokenization and normalization happen, so that matching is not defeated by trivial differences in formatting.
3. Build the inverted index — terms are mapped to the documents containing them.
4. Query — a user's query is analyzed the same way and matched against the index.
5. Rank and return — matching documents are returned, typically ordered by relevance.

Key concepts

These concepts are general to Lucene-style search. In a desktop tool, the "document" is usually a file and the "fields" are whatever the application chooses to expose — which is why the same underlying library can power very different search experiences.

How a desktop tool like DocFetcher uses it

DocFetcher is a concrete example of Lucene-style search applied to local files. According to its documentation:

• It is an open-source desktop search application that searches the contents of files on your computer — you can think of it as Google for your local files.
• It runs on Windows, Linux and macOS and is made available under the Eclipse Public License.
• You enter queries in a text field, results appear in a result pane, and a preview pane shows a text-only preview of the selected file with all matches highlighted in yellow.
• You can filter results by minimum and/or maximum filesize, by file type, and by location.
• It requires you to create indexes for the folders you want to search.

That last point is the practical consequence of how this kind of search works: the speed comes from pre-built indexes, so the first step for any folder is to index it.

Portable use

DocFetcher also offers portable versions for Windows, Linux and macOS. These allow you to create a portable document repository — a fully indexed and fully searchable collection of your important documents that you can move around, for example on a USB drive, in an encrypted volume, or synchronized between computers via a cloud drive.

Lucene directly vs. a ready-made application

The choice depends on what you are trying to accomplish.

Use a ready-made application like DocFetcher if:

• You want to search files already on your computer.
• You do not want to write code.
• You are comfortable creating and maintaining indexes for the folders you care about.
• You want filtering by size, type, and location out of the box.

Work with Lucene directly if:

• You are building search into your own software.
• You need control over what counts as a document, which fields exist, and how text is analyzed.
• You need to define your own relevance and ranking behavior.

A middle path exists as well: DocFetcher's own documentation points to DocFetcher Pro, described as the commercial big brother with more features, and DocFetcher Server, described as the commercial cousin with multi-user support and a web interface. These are relevant when the free desktop tool's scope is not enough — for example, when multiple users need to search the same collection.

Practical takeaways

• Lucene is a library, so "using Lucene" always means "using something built on Lucene."
• The speed of full-text search comes from an inverted index, not from faster scanning.
• Indexing has an upfront cost; DocFetcher's estimate of roughly 200 files per minute is a useful planning figure, and updates after changes are much quicker.
• If your goal is searching your own documents, the library-versus-application distinction matters less than picking a tool that fits: DocFetcher for local desktop search, with Pro and Server variants when you need more features or multi-user access.

Typo tolerance lets a search engine return relevant results even when the query contains misspellings, transposed letters, or missing characters—without you maintaining a manual list of synonyms or corrections. Faceting lets users narrow a result set by attributes such as category, brand, price range, or availability, typically shown as filterable counts alongside the results. In a hosted search service, both features run on the same index and query pipeline: typo tolerance expands which documents match, while faceting organizes how those matches are filtered and displayed. The two interact closely, and tuning one often affects the other.

What Typo Tolerance Actually Does

Typo tolerance is a matching strategy, not a spell checker. Instead of correcting the query and searching for the corrected term, the engine compares the query against indexed terms using an edit-distance threshold (commonly Levenshtein distance) and returns documents whose terms fall within that threshold.

Key mechanics:

• Edit distance budget: A query term can differ from an indexed term by a set number of insertions, deletions, substitutions, or transpositions. A common default is 1 edit for short terms and 2 for longer ones.
• Prefix matching: Many engines treat the last token in a query as a prefix, so "headph" matches "headphones" without counting as a typo.
• Per-word tolerance: Tolerance is usually applied per token, so "wirlress hedphones" can still match "wireless headphones."
• Ranking by closeness: Exact matches typically rank above typo matches, so results degrade gracefully rather than becoming noisy.

Because this works at query time against the index, you generally don't need to build synonym lists for common misspellings. You may still want synonyms for genuine vocabulary differences ("sofa" vs. "couch"), which is a separate concern from typos.

When typo tolerance helps most

• User-generated queries on mobile keyboards, where transpositions and dropped letters are frequent.
• Product catalogs with long, technical, or brand names that users rarely spell exactly.
• Internal document search where users half-remember terminology.

When to tighten or disable it

• Short or numeric queries: Order IDs, SKUs, or codes like "A102" can match unintended items when tolerance is loose. Consider disabling tolerance for numeric fields.
• High-precision domains: Legal, medical, or financial lookups may need exact matching to avoid surfacing the wrong record.
• Small alphabets or dense vocabularies: If many terms are one edit apart, tolerance can produce false positives.

What Faceting Adds

Faceting computes, for a given result set, the distribution of values across designated fields and returns counts per value. The user then applies filters, and the result set (and the facet counts) update.

A typical faceted interface shows:

Two design choices matter:

• Conjunctive vs. disjunctive facets: Within one facet (e.g., Brand), selecting two values usually means "Acme OR Nord." Across facets (Brand AND Category), selections combine with AND. Engines often let you choose whether a facet's own counts ignore its current selection, so users can still see sibling options.
• Count accuracy vs. speed: Exact counts are more expensive on large indexes. Some services offer approximate counts or cap the number of facet values returned.

Faceting is not the same as filtering. Filtering applies a condition; faceting computes and returns the available values and their counts so the UI can present choices. Most hosted services do both in one query.

How the Two Features Interact

This is where behavior gets interesting, and where default settings can surprise you.

1. Typo matches inflate facet counts. If "hedphones" matches "headphones," those documents appear in the result set and contribute to the Category and Brand counts. Users see counts that include loosely matched items.
2. Facet filters usually don't loosen. Once a user selects Brand = Acme, the query is constrained. Typo tolerance still applies to the text query, but it can't pull in documents outside the selected facet.
3. Relevance and counts can disagree. A typo-matched document might rank low but still be counted in a facet. If your UI shows "128 results" but the top 10 look unrelated, users lose trust.
4. Index size and field configuration affect both. Fields marked as facetable are often stored differently (as structured values rather than tokenized text), so you generally can't facet on the same field you use for fuzzy full-text matching without configuring it appropriately.

A practical consequence: tune typo tolerance before you tune facet counts, because the tolerance setting defines the population that faceting summarizes.

Trade-offs to Weigh

Performance notes: typo tolerance adds query-time work but is generally cheap relative to faceting, which must aggregate across the matched set. On large indexes, the dominant cost is usually facet computation, not fuzzy matching. Index size grows mainly with the number of facetable fields and stored attributes, not with tolerance settings.

A Workable Starting Configuration

If you're setting up a hosted search service and want sensible defaults:

1. Enable typo tolerance globally, with 1 edit for terms up to ~5 characters and 2 for longer terms.
2. Treat the final query token as a prefix so partial typing returns results.
3. Disable tolerance on identifier-like fields (SKU, order number, ISBN).
4. Mark only fields users actually filter on as facetable—category, brand, price, rating, availability. Avoid faceting on free-text descriptions.
5. Return facet counts for the top N values (e.g., 20–50) rather than all values.
6. Decide per facet whether counts should reflect the facet's own selection, so users can switch between brands without losing the menu.
7. Test with real misspellings from your logs or support tickets, and check whether the top results and facet counts still make sense.

Example: tuning by use case

• E-commerce catalog: High tolerance, many facets, counts that ignore the current facet's own selection.
• Documentation search: Moderate tolerance, few facets (product version, doc type), prioritize exact phrase matches.
• Internal records lookup: Low or no tolerance on IDs, tolerance on names, minimal faceting.

FAQ

Does typo tolerance replace synonyms? No. It handles spelling variation, not vocabulary differences. Keep synonyms for terms users genuinely use differently.

Why do my facet counts change when I type a typo? Because the matched document set changed. Counts are computed over whatever the query matched, including fuzzy matches.

Can I have typo tolerance without faceting? Yes. They're independent features that happen to share a query pipeline.

Is faceting the same as filtering? Filtering applies a constraint; faceting computes available values and counts. Most interfaces use both together.

Will enabling both slow down search? Faceting is usually the larger cost. Measure with your own data rather than assuming.

The short version: typo tolerance decides what counts as a match, faceting decides how matches are organized and narrowed. Configure tolerance first, keep facetable fields deliberate, and verify that the counts your users see reflect results they'd actually recognize.

DocFetcher is an open-source desktop search application that indexes the contents of files on your computer so you can search them like a local Google. It runs on Windows, Linux, and macOS under the Eclipse Public License. Use it when you need to find text inside documents — not just filenames — and you're willing to spend a one-time indexing pass per folder to get millisecond-level search afterward. If you only need to search filenames, or you need multi-user access, a different tool fits better (see the last section).

How DocFetcher works: indexes, not live scanning

DocFetcher doesn't read every file each time you search. Instead, it builds an index for each folder you want to search. The index records which files contain which words, so a query resolves in milliseconds rather than scanning your disk.

Two consequences follow from this design:

• You must create an index before searching a folder. A folder that isn't indexed won't return content matches.
• Indexing is a one-time cost per folder. After the initial build, updating the index when files change is much faster — usually a few seconds.

The homepage gives a rough throughput estimate of 200 files per minute for the initial indexing, so a folder of 10,000 files is roughly a 50-minute job the first time. Plan the initial index for a quiet moment; later updates are cheap.

Setting up an index

1. Open the index-creation dialog from the main interface.
2. Point it at the folder (or folders) you want searchable.
3. Click Run at the bottom right of the dialog to start indexing.
4. Wait for the process to finish. Progress depends on the number and size of files.

Once the index exists, you don't repeat this step for that folder — you only refresh it after the contents change.

Running a search

The main window is organized around three panes and a set of filters:

The practical workflow: type a query, scan the result pane, click a result to read the preview with matches highlighted, then narrow with the size, type, or location filters if the result set is too broad. Buttons on the interface open the manual, open preferences, and minimize the program to the system tray.

Portable versions and a movable document repository

Portable builds exist for Windows, Linux, and macOS. They let you build a portable document repository: a fully indexed, fully searchable collection of your documents that you can move freely. According to the project, you can carry it on a USB drive, package it for archival, place it in an encrypted volume, or synchronize it between computers via a cloud drive.

This is the feature to care about if your documents travel with you or need to live in one self-contained, searchable bundle rather than on a single machine's fixed folder structure.

When to look beyond the base version

The same page points to two commercial siblings:

• DocFetcher Pro — described as the commercial "big brother" with more features.
• DocFetcher Server — described as the commercial "cousin" with multi-user support and a web interface.

Choose the open-source DocFetcher when you're a single user searching local folders and the feature set above covers your needs. Consider Pro if you want more features than the free version provides, and Server if several people need to search the same index through a browser rather than a desktop app. The homepage doesn't list prices for either commercial product, so check the linked pages for current terms before deciding.

Desktop search is full-text search over files stored on your own computer, rather than over the web. It works by building a local index that maps words to the files containing them, so a query can return matches in milliseconds instead of scanning every file on disk. Tools like DocFetcher implement this: it runs on Windows, Linux, and macOS, is open-source under the Eclipse Public License, and its documentation describes it as "Google for your local files." The trade-off is a one-time indexing cost per folder, after which searches and index updates are fast.

Desktop search vs. web search

The two solve different problems with different data:

If your question is "which of my files mentions this term," desktop search is the right tool. If it's "what does the internet say about this term," it isn't.

How indexing makes search fast

Without an index, a search tool must open every file and scan its contents — work that grows with the size of your document collection. An index inverts that relationship. As DocFetcher's documentation puts it, an index lets the application "find out very quickly (in the order of milliseconds) which files contain a particular set of words."

The mechanism is a word-to-file mapping. When you index a folder, the tool parses each file, extracts its terms, and records which files contain which terms. A query then looks up the terms in that structure rather than touching the original files. DocFetcher builds its indexes on Apache Lucene, a widely used full-text search library, which is why the same query behavior — term matching, result ranking — resembles what you'd see in other Lucene-based systems.

The typical workflow

1. Choose folders to index. DocFetcher requires you to create an index for each folder you want searchable. Nothing outside an indexed folder is searchable.
2. Build the index once. In the index-creation dialog, clicking "Run" starts the process. This is the slow step.
3. Run queries. Enter a query in the text field; results appear in the result pane, and selecting a result shows a text-only preview with all matches highlighted in yellow.
4. Update after changes. When folder contents change, update the index. DocFetcher's documentation notes this "usually takes only a couple of seconds," far less than the initial build.

What to expect from the interface

DocFetcher's main window exposes the features that matter for narrowing a result set:

• Result filtering by minimum and/or maximum file size, by file type, and by location.
• Preview pane showing a text-only rendering of the selected file, with matches highlighted.
• Utility buttons for opening the manual, opening preferences, and minimizing to the system tray.

These are the capabilities worth checking for in any desktop search tool: filtering by metadata, and a preview that shows why a file matched rather than just that it did.

Trade-offs to plan around

Initial indexing takes time. DocFetcher's documentation gives a rule of thumb of roughly 200 files per minute. A folder of 10,000 files is therefore on the order of 50 minutes of indexing — a background task, not an interactive one. The cost is paid once per folder.

Updates are cheap. Because only changed files need reprocessing, keeping an index current is a seconds-scale operation. This is what makes the initial cost acceptable.

Portable indexes change where search can live. DocFetcher offers portable versions for Windows, Linux, and macOS that let you build "a fully indexed and fully searchable repository of all your important documents that you can freely move around." The documentation lists carrying it on a USB drive, packaging it for archival, placing it in an encrypted volume, or synchronizing it between computers via a cloud drive as intended uses. In practice this means the index and the documents travel together, so search works without rebuilding on each machine.

Open source, with commercial siblings. DocFetcher itself is open-source. Its documentation points to DocFetcher Pro (more features) and DocFetcher Server (multi-user support and a web interface) as commercial alternatives — relevant if you need shared or multi-user search rather than a single-user desktop tool.

Deciding whether to use one

Desktop search is worth setting up when you have a large, relatively stable body of local documents — contracts, research PDFs, source trees, archived mail — and you repeatedly need to find which files mention a term. It is less useful for a handful of files you can open directly, or for content that lives primarily in a web application or shared drive you don't control. If you do adopt it, index the folders you actually search, expect the first build to take real time, and rely on incremental updates afterward.