How to View Folders and File Names Matching Query in Search Results - DocFetcher
Desktop search application
Brought to you by:
qforce
Menu
▾
▴
I've seen a couple posts about this topic, but not a thread in particular that was focused on it as the primary question. Feel free to delete if redundant. DocFetcher is such a great search program, but not having this capability is inconvenient at best. I'd be interested to know the inside story of why. I realize no feature requests are being addressed at this time, but perhaps there is a workaround? What do you suggest? Thanks!
My Operating System is Windows 10.
I'm running DocFetcher that I downloaded in March 2019 (version 1.1.22, according to the Help file).
Hi,
What does that mean? Example?
Best regards
q:-) <= Quang
CORRECTION
It seems that I was mistaken about File Names.
DocFetcher Syntax:
filename:text-stringor,
title:text-stringQUESTION CLARIFICATION
In the Windows operating system, I want to search for folder names.
How is that accomplished in DocFetcher?
EXAMPLE
Let's say I have a folder named, "Audio Tools" which resides in the path, "F:\Utilities\Media\Audio Tools\". Then, let's assume I've already indexed the root folder, "F:\Utilities". Then, when I do a search for
title:audio tools, orfilename:audio tools, or simplyaudio tools, that folder does not appear in the results.NOTE: It also seems that empty folders names are not indexed, or even it they are in the indexed database, there is no way to get them to show up in the search results. Is there a workaround? Is there a way for me or one of us users (developers) to access the database to grab and manipulate the results to show such folder names? It would be nice to have a syntax such as,
folder:text-string, or if the filename operator were extended to include folders.Last edit: Jerry Leventer 2019-03-07
DocFetcher does not include folders or file paths in the search, only filenames and file contents. As to why, that was a fundamental design decision that was made back then when the core program was written, with the idea being that (1) most of the important stuff the user may want to search for is in the file contents, and (2) there are already a lot of programs to search in filenames and folder names, such as Everything.
Also, if you use field search, you have to put the field value in quotes if it contains spaces:
title:"audio tools"
filename:"audio tools"
Thank you for explaining your philosophy. I am forced to wonder how many users agree with you. For me, it is more than just an inconvenience, it is a deal breaker. I am gravely disappointed. DocFetcher has lost it's place as the first and primary search tool I will use. I am forced, it seems, to find another tool. Maybe Everything, as you suggest. We were so close...
I need to agree with Jerry... you have a AWESOME piece of software here... but folder names are essential for what I use it for. I would love an option in the future to index folder names.
docfetcher + everything = everything... but everything is not quite everything, docfetcher is, minus folder names. Include the option and rename it everything^2
=)
It's not that I'm "against" folder name search, I just don't have the time to implement major changes like this.
Thanks for your reply, Quang. And thanks for your comments, Shawn.
I would like to know, in your opinion, how much time would it take someone else to understand your source code and to implement the changes? How much time did it take you to develop? What might it take to help persuade you to perform the requested update, or perhaps work with others to achieve?
Here are some questions I, myself, would research before attempting the project.
Maybe someone can help take it on as a group project?
Is there someone who would like to assist me in reviewing this?
DocFetcher was written in Java. There are no specs, flow diagrams, etc., just a basic readme and the source code, with code comments only at difficult parts. However, I've been told numerous times that my code is very easy to read, despite the lack of documentation and comments.
As for folder name searching, the problem is this:
DocFetcher's indexing algorithm, the core of the program, is crazy complicated and by far the hardest part to understand. This is due to unlimited recursion into nested archives, pairing of HTML files and their corresponding "_files" folders, handling of archives with solid compression, and other features. If I remember correctly, it took me several months just to implement this indexing algorithm.
The assumption that folder names can't be searched runs through the entire program and especially through that hard-to-understand indexing algorithm. Thus, my first guess is that I would need a full month to integrate folder name search into the existing indexing algorithm, as well as into other affected parts of the program. If someone else were to do it, it would have to be a professional Java developer, and they would probably take at least twice as long.
I'm completely tied up by another project and simply can't afford to sink that much time into this feature. And even if I were to be paid for it, I would still feel uncomfortable with trying to patch up 7 year old code that is crazy complicated, has a ton of other problems and is in dire need of a full rewrite.
Thank you for taking the time to explain on this issue. If you every decide to try to attack it again, perhaps in a different language too, please keep us in the loop.
On the DocFetcher SourceForge.net page, there's a "Get Updates" button that allows you to subscribe to new DocFetcher releases: https://sourceforge.net/projects/docfetcher/
That's as "in the loop" as it gets.
The change log on the DocFetcher wiki is the place to go to if you want to know what's in the release: http://docfetcher.sourceforge.net/wiki/doku.php?id=changelog
DocFetcher is now legacy software and will not be developed further, it will only receive bugfixes from now on. However, folder name indexing has been implemented in DocFetcher Pro, the recently released commercial spinoff of DocFetcher.