FAQ

Go to gumroad.com and click on the “Login” button in the top right. On the following page, click the “Sign up” link at the top of the page. Now fill in your email address and password in the fields further below on the page and click the “Create account” button.

To get the latest release files, log in to the gumroad.com account with which you purchased DocFetcher Pro or DocFetcher Server. In your account, clicking “Library” on the left will take you to a list of the products you purchased on Gumroad. Among these products should be DocFetcher Pro or DocFetcher Server, and clicking these will take you to the latest release files.

When upgrading from one version of portable DocFetcher Pro or from one version of DocFetcher Server to a newer version, do not unpack the new version on top of the old version. This will get program files mixed up, potentially causing abnormal program behavior. Here’s the correct way to upgrade the program and also keep your settings and indexes:

1. Unpack the new program version to a fresh location.
2. Copy only the folders conf and indexes from the old program folder to the new program folder.
3. Copy from the old program folder to the new program folder any files you modified by hand.

Note: If you’re using non-portable DocFetcher Pro, then on Windows (and only on Windows) you can safely install the new program version in the same folder as the existing version (e.g., C:\Program Files\DocFetcher Pro). This is safe because the installer will automatically remove the existing version before installing the new one. The installer will also retain any existing settings and indexes. On platforms other than Windows, non-portable DocFetcher Pro must be unpacked to a fresh location, and it will reuse any existing settings and indexes in your home folder.

As for DocFetcher Server, all release files of DocFetcher Server are portable, so the above upgrade procedure for portable releases applies.

DocFetcher Pro

How the settings and indexes from the DocFetcher Pro demo can be transferred to the full version depends on the DocFetcher Pro version you’re using:

• Windows, non-portable (installed): Open the folder C:\Users[Your Username]\AppData\Local. In that folder, you’ll find a folder named DocFetcher Pro Demo. Make a copy of it in the same location by selecting it and pressing Ctrl+C and then Ctrl+V. Rename the copy to DocFetcher Pro. If there was already a folder named DocFetcher Pro, then rename the latter to something else or remove it before renaming the copied folder.
• Linux and macOS, non-portable: In your home folder, rename the folder .docfetcherprodemo to .docfetcherpro. Rename or remove an existing .docfetcherpro folder beforehand if there is one.
• Any platform, portable: Copy only the folders conf and indexes from the demo program folder to the full version program folder.

Note that the above instructions assume that you wish to transfer settings and indexes from a non-portable demo to a non-portable full version, or from a portable demo to a portable full version. Transferring between non-portable and portable is also possible and essentially just comes down to locating the conf and indexes folders and copying them to the right place.

DocFetcher Server

To transfer the settings and indexes from the DocFetcher Server demo to the full version, copy only the folders conf and indexes from the demo program folder to the full version program folder.

DocFetcher has a misc/paths.txt file that allows customizing the location of the indexes. In DocFetcher Pro, the misc/paths.txt file is gone without replacement for technical reasons (namely known bugginess and program instability), so relocating the indexes that way is not possible with DocFetcher Pro. However, there is still another way: In the portable versions of DocFetcher Pro, the indexes are inside the program folder, and this folder can be moved around freely.

As for DocFetcher Server, it is essentially a portable application on all platforms, so to relocate the indexes you can simply move the entire program folder.

Pausing and resuming indexing is possible in both DocFetcher Pro and DocFetcher Server, but the functionality is somewhat non-obvious: Just abort the current indexing process. In the case of index creation and index rebuilding, you’ll then be asked whether to keep or discard the partially created index. Select “keep”. When you want to resume indexing, select that partial index and run an index update on it. It may take some time for the application to find the spot where indexing was aborted previously.

Suppose there is a file “cat-dog-mouse.pdf” among your indexed files. Entering the search query “*dog*.pdf” (without the quotes), you’d expect the application to turn up the file “cat-dog-mouse.pdf”, but it doesn’t. To understand why, and to understand how to work around the issue, a deeper understanding of the indexing process is needed.

To begin with, there is an application-wide setting called “Word segmentation”. It determines how the streams of text that are being shoved into the indexing engine are split into individual, searchable words.

The default value of the word segmentation setting is called “Standard” and works well for the kind of text you’d typically find in documents written in a natural language such as English. The Standard word segmentation splits the text at spaces, hyphens (i.e., “-“) and other characters. It does not split at dots (“.”) or underscores.

This behavior makes sense for document text, but the way it affects filename handling may be unexpected. In the example above, the filename “cat-dog-mouse.pdf” would be split into “cat”, “dog” and “mouse.pdf”. That’s why the query “*dog*.pdf” does not match it.

There are basically two ways to work around this issue:

1) Change the word segmentation setting, specifically to “Whitespace”. As its name suggests, the “Whitespace” option splits the text only at whitespace characters, nothing else. Thus, the filename “cat-dog-mouse.pdf” would be left intact when passed to the indexing engine. However, changing the word segmentation may have a significant and possibly undesirable impact on all your searches. Moreover, it requires rebuilding all your indexes.

2) Use a different search query. In the example above, the following queries would work:

• *dog*
• *mouse*.pdf
• "cat-dog-mouse.pdf"

In addition, the query “cat-dog-mouse.pdf” without quotes would also work. This is due to another detail in how the search engine works: Not only the indexed text, but also the query itself is split using the chosen word segmentation algorithm, which in the present example results in “cat”, “dog” and “mouse.pdf” .

Finally, note that there is a “Document Types” pane on the left side of the UI. This pane offers a much more reliable way to narrow the search down to specific file types, compared to the above method of including the file extension in the search query.

There are two likely reasons: First, the “Use type-ahead search” option in the preferences can have a significant impact on performance. If it’s enabled, try disabling it.

Second, it’s possible that you have indexed one or more very large folders, and that these folders are being frequently modified in the background, triggering continuous index updating in DocFetcher Pro and thus slowing the latter down. In that case, try turning off automatic index updating on all indexes. To do so for a single index, right-click on it in the Search Scope pane and uncheck “Auto-Update Index”. Alternatively, you can disable automatic index updating on all indexes at once by launching the program with a --disable-auto-index-update argument.

The page “Index Updates” in the user manual explains how DocFetcher Pro’s automatic index updating works, and what the alternatives are when automatic index updating is not available.

No, but there’s a workaround. For some context: On Windows and Linux, the free DocFetcher has a global hotkey (by default Ctrl + F8) to bring the program window to the front. This feature was not carried over to DocFetcher Pro as the hotkey is known to cause stability issues. However, it is possible to emulate the hotkey with additional software, as explained below. How to emulate the hotkey on macOS will not be explained, but it can be done with Automator and AppleScript.

On Windows

1. Download the open-source software AutoHotkey from here and install it. Afterwards, restart Windows.
2. Press Windows key + R, type shell:startup, then press Enter. This opens your startup applications folder.
3. Right-click in that folder and select New > AutoHotkey Script. Give the new .ahk file a name, e.g., DocFetcher Pro Hotkey.ahk. The .ahk file is a script that will be run every time Windows starts up.
4. Right-click the .ahk file, then select Edit Script.
5. Replace all text in the .ahk file with this:

^F8::
if WinActive("DocFetcher Pro") {
    WinMinimize, DocFetcher Pro
} else {
    WinActivate, DocFetcher Pro
}

6. Save and close the .ahk file.
7. Restart Windows.
8. From now on, you can press Ctrl + F8 to bring a running DocFetcher Pro instance to the front. After pressing Ctrl + F8, you can further press Ctrl + F to focus the search field in DocFetcher Pro. If you press Ctrl + F8 while DocFetcher Pro is already the active window, it will be minimized instead.
9. The ^F8:: line in the .ahk script above is what binds the script to the Ctrl + F8 hotkey. For other hotkeys, see this page in the AutoHotkey documentation.
10. To learn more about AutoHotkey, see the AutoHotkey documentation, and the tutorial in particular.

On Linux

1. Install AutoKey. On Debian-based distros such as Ubuntu, run this command in the terminal: sudo apt install autokey-gtk
2. If not already installed, install the following dependencies: wmctrl and xdotool.
3. Start AutoKey.
4. In AutoKey, create a new script: File > New > Script
5. Paste the following code into the code editor:

output = system.exec_command("wmctrl -lx", getOutput=True)
if "DocFetcher Pro.DocFetcher Pro" in output:
    winClass = window.get_active_class()
    if winClass == "DocFetcher Pro.DocFetcher Pro":
        system.exec_command("xdotool windowminimize $(xdotool getactivewindow)")
    else:
        system.exec_command("wmctrl -x -a "DocFetcher Pro.DocFetcher Pro"")

6. Beneath the code editor, assign a hotkey, e.g., Ctrl + F8.
7. Add AutoKey to your startup applications. You can do this from within AutoKey: Edit > Preferences > Automatically start AutoKey at login
8. Save the script and close the AutoKey window. It’ll keep running in the background.
9. From now on, you can press Ctrl + F8 to bring a running DocFetcher Pro instance to the front. After pressing Ctrl + F8, you can further press Ctrl + F to focus the search field in DocFetcher Pro. If you press Ctrl + F8 while DocFetcher Pro is already the active window, it will be minimized instead.

Let’s assume you followed the setup instructions in the documentation and got DocFetcher Server up and running to the point where you can access it locally, i.e., on the server machine, via a URL like this: http://localhost:31190/

However, when you try to access it from the outside using your server machine’s address, e.g., http://192.255.234.105:31190/, your browser only displays an error message.

Possible explanations:

• If your server machine sits in a local network and connects to the outside world through a router, you need to set up port forwarding on the router.
• Access to the DocFetcher Server instance may be blocked by a firewall. It could be a firewall in your router, a firewall of your web hoster, or a firewall on the server machine itself (e.g., Windows Firewall, UFW).

The users that are counted towards the client limit of a DocFetcher Server instance are not identified by IP addresses, but by browser sessions. This has the following non-obvious implications:

• Accessing the server from two different browsers on the same computer — counts as 2 users.
• Accessing the server from a private and a non-private tab in the same browser — counts as 2 users.

From a user perspective, this is admittedly not ideal, since accessing the server from the same computer in multiple ways is still really only one “seat”. However, the alternative, counting by IP addresses, is technically infeasible because IP addresses are generally not a reliable way to identify users.

In particular, if two users access a server from behind a NAT firewall or a proxy server, the server being accessed would see both users as having the same IP address. Thus, DocFetcher Server’s client limit could easily be circumvented by using a proxy server.

For an extended technical discussion of the IP addresses vs. browser sessions issue, please see this page and this page on Stack Overflow.

DocFetcher Server offers a workaround called session stealing that makes switching between different browsers on the same computer as well as switching between different computers more convenient. Session stealing means that when the client limit is reached, new users are able to take over existing sessions, thus kicking their previous owners out of the web interface. The intended use is for users to kick themselves out in order to more easily switch between browsers and/or computers. For instances of DocFetcher Server with a client limit greater than 1, session stealing is off by default and must be enabled in the Admin Area on the Access tab.

Short answer: No, but there’s a (somewhat clunky) workaround.

Long answer: For security reasons, modern browsers are designed to run web applications in a sandbox. The DocFetcher Server web UI is such a web application, and this is why it cannot access the local file system outside the browser and open files, and instead lets you download them.

The workaround: In the web UI, copy the file path of the search result to the clipboard, then paste it into your file manager or some other application that can handle the file path. For example, in Windows Explorer you can open a file by pasting its path into the path bar.

DocFetcher Server has two features to support this copying and pasting of file paths. First, in the Admin Area, go to the Miscellaneous tab, then at the setting “Click on icon in search results”, select “Copy path”. This allows the clients to conveniently copy a search result’s file path by clicking its icon.

Second, depending on your setup, the file paths the DocFetcher Server instance sees may not necessarily be identical to the file paths the clients see. For example, the DocFetcher Server instance may be running on Linux and indexing files under /path/to/files, whereas the clients may be running on Windows, seeing the indexed files on a network drive mounted at X:\. The solution to this path mismatch: In the Admin Area, go to the Indexes tab, select an index, then click the “Client Path…” button under the indexes table, then enter a custom path to show to the clients. Do this for every affected index.

There’s no roadmap, just a mountain of feature requests and a vague idea of where the project might go in the future. Many years of experience with DocFetcher have shown that concrete feature plans rarely pan out, often due to sheer technical difficulties and/or because too many other features are also vying for developer attention.

For example, a web interface of DocFetcher was “planned” all the way back in 2008, but it wasn’t until 2022 that DocFetcher Server 1.0 saw the day of light, after a full year of development.

Please refer to the refund policy.