Fast File Finder  Fast File Finder

go to home page Student Projects full screen, hide local find menu Google search web for more information on this topic jump to foot of page translate this page with Babelfish ©1996-2009 Roedy Green, Canadian Mind Products
This essay does not describe an existing computer program, just one that should exist. This essay is about a suggested student project in Java programming. This essay gives a rough overview of how it might work. I have no source, object, specifications, file layouts or anything else useful to implementing this project.

This project outline is not like the artificial tidy problems you are spoon-fed in school, when all the facts you need are included, nothing extraneous is mentioned, the answer is fully specified, along with hints to nudge you toward a single expected canonical solution. This project is much more like the real world of messy problems where it is up to you to fully the define the end point, or a series of ever more difficult versions of this project, and research the information yourself to solve them.

Everything I have to say to help you with this project is written below. I am not prepared to help you implement it; or give you any additional materials. I have too many other projects of my own.

Though I am a programmer, I don’t do people’s homework for them. That just robs them of an education.

You have my full permission to implement this project in any way you please and to keep all the profits from your endeavor.

Please do not email me about this project without reading the disclaimer above.

The File Find that comes with Windows a is inept. It is very slow because uses a brute force search of the entire disk. When it shows you the results it won’t let you copy/paste them. Why else were you looking?

Your task is to write a platform independent Fast File Find. I suggest you tackle it like this:

  1. Create a SQL database of all the filenames in the system.
  2. Ask SQL to build three indexes, by directory name, by filename, and by extension.
  3. When you get a request, analyse the wild card and convert it into a SQL query on those three fields. SQL will be clever and use its indexes or brute force if necessary. In any case it will always be faster than the Windows File Find since its database is contiguous. The directory that Windows searches can be scattered higgledy piggledy all over the disk.
  4. If you don’t want to use SQL, you will need some sort of treemap/btree indexed file manager. Btrieve will let you package their product free with your apps, but that only covers Windows.
  5. Allow copy to the clipboard of any result with a single click, as well as the traditional ways.
  6. Allow launch of any of the result files with a double click, ideally support everything in the Windows right click menu for that file type.
  7. Now for the hard part. How do you keep your SQL database up to date?
  8. Now you can get a little clever. You can do lazy updates of deleted files, procrastinating discovering and telling your SQL database about them. Don’t bother checking if the files exist until they show up in a result list of someone’s SQL query. Then at the last second check if the files still exist, and update the SQL database accordingly. You can also discover them with a low priority background process.
  9. Of course you want something that at 3 AM refreshes the database and ensures it is not corrupt in any way and is 100% up-to-date.
  10. For bonus points, in your displays, mark files that are in-use, or open-for-write. You can use File. canWrite or some platform specific code to find files that are being read too.
  11. Consider a more elaborate user interface that looks something like this: Sorry, you need Java 1.1+ to run this Applet.

    If, ff, the above FileFinder Java Applet does not work…

    1. This Java Applet needs Java 1.1 or later, version 1.6.0_17 recommended and a recent browser.
    2. You should see the Applet above looking much like the screenshot. If you don’t, the following should help you get it working:
    3. If you are using Microsoft Internet Explorer, try another browser. Seriously. Microsoft has taken great pains, over and over, to screw up Java and every other multi-platform standardisation.
    4. If you are using Internet Explorer 7 or 8, you must allow blocked content permission for Active X to run. This also gives permission to Java to run. Click the Information bar, and then click Allow blocked content. Unfortunately, this also allows dangerous ActiveX code to run. However, you must do this in order to get access to perfectly-safe Java Applets running in a sandbox. This is part of Microsoft’s war on Java. Don’t put up with it! Use a different browser.
    5. Especially if this Applet has worked before, try clearing the browser cache and rebooting.
    6. To ensure your Java is up to date, check with Wassup. First, download it and run it as an application independent of your browser, then run it online as an Applet to add the complication of your browser.
    7. If the above Applet does not work, check the Java console for error messages.
    8. If the above Applet does not work, you might have better luck with the downloadable version.
    9. If you still can’t get the program working click HELP for more detail.
    10. If you can’t get the above Applet working after trying the advice above and from the HELP button below, have bugs to report or ideas to improve the program or its documentation, please send me an email atemail Roedy Green.
    Java powered   Get New Java  Get New Browser   Help

Why JNI?

You could do this by polling directories in a platform-independent way. Why would You want to take the clean, system-independent Java solution and replace it with a half-dozen native implementations?

The reasons I originally wanted to write a file find to replace Microsoft’s are:

  1. I wanted it much faster.
  2. I wanted it low overhead.
  3. I wanted it up-to-date. I most often search for a file that I recently saved under the wrong name.
Given that a Java method for a global hook in a platform-independent way to monitor changes is not available, and polling is both slow and a huge drain on resources, I see no alternative but JNI or other native hook for an efficient implementation. Think of it as doing Sun’s work for them, providing the hook to everyone (who has sufficient privilege).

One nice thing about native classes is you can add more implementations later without disturbing existing code. JWS selects the right library for you.

FindCat

I experimented with Robert Swanson’s beta implementation of a fast file finder called FindCat32. It sooo fast! I find myself using it far more frequently than I ever used the Windows equivalent. It is even faster to use it to find a file than to click to it with the Windows Explorer, even when you know exactly where it is. FindCat32 also lets you push the filename to the clipboard which saves retyping. FindCat does not let you use wildcards, or regexes, and it does not monitor file changes, but those features may be in the pipe. It uses a fairly simple flat file structure with various indexes.

Desktop Google has provided a fast search, but by content, not by name.

Copernic
file monitor
Google Desktop
JNotify

CMP homejump to top You can get the freshest copy of this page from: or possibly from your local J: drive (Java virtual drive/mindprod.com website mirror)
http://mindprod.com/project/filefinder.html J:\mindprod\project\filefinder.html
CMP logofeedback Please email your feedback for publication, errors, omissions, typos, formatting errors, ambiguities, unclear wording, broken/redirected link reports, suggestions to improve this page or comments to Roedy Green : feedback email
mindprod.com IP:[65.110.21.43]
view BlogYour face IP:[38.107.191.108]
You are visitor number 12,705.