DocFetcher Portable 1.1.25 Dev Test 1

DocFetcher developer here. Tested with a non-portable Java installation. No problems were found, two thumbs up!

Oustanding news. I use this program at least once a week both at work and at home, saving me a ton of time and energy.

Thanks, mwayne.

I am a big DocFetcher fan and am keen to switch to using the PortableApps version 1.1.19, as it was the last to use the older edition of Lucene.

The bug I have encountered involves the "settings-conf.txt file" and relates to an error that happens when 2 or more PortableApps versions of 1.1.19 are being run at the same time out of separate folders, but I suspect that same error will happen when using any of the PortableApps versions released to date.

From what I have observed, when the program is first installed, the settings-conf.txt file resides in the “settings” folder: X:\DFPortable 1.1.19\Data\settings\

When the program launches, the settings-conf.txt file is moved to the “conf” folder: X:\DFPortable 1.1.19\App\DocFetcher\conf\

When the program is closed, the settings-conf.txt file normally gets returned to the “settings” folder, but not always.

On occasion, I have seen a settings-conf.txt file reside at both locations when the program is running.... and the two files are different. The one in the settings folder will show Column Ordering values but the other one will be blank as to this setting and sometimes the file will be entirely blank.

Having both the program and the settings config files together in the “conf” folder on re-launch doesn’t necessarily cause a problem but it seems that on the next launch, the program will sometimes realize that the “settings” folder is empty and then generate a replacement settings-conf.txt file which then overturns the users preferred settings AND at the same time, any existing Indexes are lost.

Editing or replacing the settings and program config files with known “good” ones restores the preferred settings but not the missing index(es).

Bizarre as it may seem, the only definite factor I have observed that can delay the return of the settings-conf.txt file to the “settings” folder on program closure is when another iteration of DF is running. Three times I have seen the “missing” settings-conf.txt file return to the “settings” folder just moments after the second iteration of DF was closed. In two such cases, the primary version of the PortableApps DF had been closed at least 5 minutes earlier.

Here’s how to duplicate the problem.

1. Open a primary PortableApps version of DF and continuously observe its “settings” folder.

2. Open a secondary separately located PortableApps version of DF.

3. Close the primary version of DF and observe that the settings-conf.txt file does not return to its “settings” folder.

4. Close the secondary version of DF and observe that the primary settings-conf.txt file then returns to its “settings” folder.

Next, substitute a version of the "official" DF Portable for the secondary PortableApps version of DF and repeat the experiment.

Observe that the return of the primary settings-conf.txt file to its “settings” folder is dependent on the closure of the secondary DF Portable.

Factors possibly involved:
From my discussions with the author of DF, the official versions create a file named .lock-XXXXX, where the XXXXX is a long sequence of seemingly random characters and the file resides in the Windows temp folder. After launch, DocFetcher checks whether this .lock file already exists; if it does exist, DocFetcher knows that at least one other DocFetcher instance is running or was forcibly terminated.

From what I can see, this detection mechanism works fine in the official DocFetcher versions, but not in the PortableApps version.

In the official DocFetcher versions, the user will consistently be asked to confirm whether he/she wants to launch another DocFetcher instance. PortableApps DocFetcher on the other hand will open a second instance without confirmation, and will only ask for confirmation if you then try to launch a third instance. Allowing 2 but not 3 versions to run seems to me to be quite odd, and presumably is unintended behavior.

At any rate, I understand that while simultaneously running multiple instances of the same DocFetcher installation is generally a bad thing because DocFetcher is not designed to share its settings and other program files with instances of itself, running multiple copies of the official portable DocFetcher is no problem as long as they reside in separate DocFetcher folders, but the PortableApps version of DF will not allow this to be done without the reported bug eventually occurring.

Unrelated recommendation:
The PortableApps version of DF is issued with provision for only 512MB of memory. This is often inadequate and I have experienced PortableApps DF run out of memory when indexing only some 750 rtf files that contain nothing but text and make up a total size of only some 35 Mb. I suggest that the out of the box memory be increased to 1GB minimum.

Love what you guys are doing by the way!

Ronnz

Thanks for your early response Ken.

While this may not address the difficulties I have encountered, may I suggest that a minimum solution would be to:

1. Ensure that on any attempt to launch a second (not third) iteration, the user be warned that settings may be lost etc and that,
2. The program ships with a standard 1GB of memory.

Hi all,

the help file says that the alternative launchers "are inside the DocFetcher\misc folder", but this folder only contains "licenses.zip" and "paths.txt" in my case. Are there alternative launchers in the portable version?

Thanks,

DocFetcher developer here. A new DocFetcher 1.1.24 release is out. Changelog is here.

DocFetcher was upgraded to 1.1.25 due to a major bug in the previous version.