• If you get a window shown by FAF that mentions Internal Error (exception) and creates a text file on your desktop that contains the textUITools.NewPictureFromPicWithMask, then you may be running an outdated Mac OS X Snow Leopard version. Please update to at least 10.6.4, that should fix it.
• If you get a crash saying Find Any File was quit unexpectedly, you may have a conflicting Input Manager or Input Method installed, such as SIMBL or Spell Catcher. While these are not generally harmful, they are, regrettably, causing problems for Find Any File. To keep using FAF, check the folders named InputManagers and Input Methods in your startup disk's Library folder and remove their contents temporarily, then reboot, to see if FAF works then. Unfortunately, it's out of my control to fix FAF in this regard. For more detailed instructions on how to go about sorting out the offending software causing the crash, you may follow this guide of mine: How To Identify and Disable software extensions on OS X that cause other Apps to crash
• There also used to be a issue caused by an update of Airfoil from Rogue Amoeba in August 2011. You should have updated Airfoil by now. See Rogue Amoeba's article on this topic.

There are several possiblities:

• The Hot Key Agent crashes - This happens on OS X Tiger. To fix this, update from version 1.6 to 1.6.1
• Install Hot Key at Login does not work - This happens on PowerPC Macs. To fix this, update from version 1.6 to 1.6.1
• Find Any File does not launch when the Hot Key is pressed - This can happen if you've moved Find Any File after activating the Hot Key. Simply open the Preferences in Find Any File once, that should fix it.

This can happen if you have other versions of FAF left on your startup disk.
To find them, you can download my tool Locate App By Bundle ID, letting it search for "org.tempel.findanyfile". Then move the found app to the Trash. Repeat these steps until no more FAF versions are found.

Please update to version 1.6 or later via the App Store, and launch that new version of Find Any File once. After that, you can replace the App Store version with the version from my website here and you won't get this reminder any more. There is also another way around this - just send me an e-mail and I'll give you instructions to turn off the reminder.

Please update to version 1.6 or later, quit FAF, enter the command again, press Return, quit Terminal.app and relaunch FAF. Then check if the menu, right above "Preferences...", shows an entry titled "Purchase...". If that still appears, the registration didn't work. Please contact me so I can help you get this fixed. If you don't see "Purchase..." under the "Find Any File" menu, then the app has been registered and should not show the reminder again.

This usually means that the search includes very large or network volumes.
Time Machine is one of those very large ones. It easily has ten times more file records on it than the average disk. I am working on a way to exclude the Time Machine volume when searching "all disks". Until then, you have to search individual volumes if you want to avoid the long delay, sorry.

This happens if you are using FileVault on OS X 10.6 (Snow Leopard) to secure your personal data (not an issue on 10.7 Lion any more). This effectively turns your home folder into a (somewhat hidden) separate disk, and Find Any File is not aware of this yet. To work around this, you need to make sure the FileVault is searched separately. It appears in the Disks list as its own item, named after your account's short name.

If you read the FAQ further down, you'll see that some volumes support the "fast search" operation. That's what makes FAF so fast.
Volumes that do not support this operation are marked with "(slow)". Expect long times when searching on those.

Such items, usually called Packages or Bundles, are actually folders that are specially treated by the Finder. And Find Any File currently does not show the sizes of folders because that would cause a general slowdown as all the files inside a folder would have to be looked at to create a sum of their sizes.

I plan, however, to change this behavior a little in an upcoming release so that the sizes for these Bundles will be calculated as those folders are usually relatively small, thus causing hardly any performance penalties.

Generally, some files, mainly older ones, are made up of two so-called forks. While one fork, the data fork, contains the actual file data, there is another fork, the resource fork, which contains meta data that's often not really important but provides additional information specific to Mac OS, while it can be ignored on other systems, e.g. Windows and Linux. Now, when you search for size, you get to specify the data fork's size only. But the results list shows the files' total sizes, i.e. the sum of both forks, if available. This means that the results are still correct, as their data fork size is indeed zero, while they may have also a non-empty resource fork. To see the specific fork sizes, enable the Show Tooltips option under the View menu and then hold the mouse over a found item for two seconds.

There is a solution to this, and it's the same the Finder and many other applications offer in their hierarchical list views: Hold down the Option (alt) key when clicking the triangle. That will affect all the folder's contents, opening or closing them all at once.

FAF hides these options now by because because they're rarely used nowadays and caused confusion for new users not understanding what this old "file type" was about.

If you understand that these are hidden 4-letter codes and have nothing to do with what the "Kind" column shows, you can enable the expert mode in FAF. To do that, issue the following command in Terminal: defaults write org.tempel.findanyfile "Mode.Expert" -bool YES

The "file type" supported by FAF is an old concept from pre-OS X, when Mac OS didn't use file name extensions to define a type but a 4-letter code. Problem is that these codes are hardly used now any more. Yet, FAF still supports them because it can.

If you want to look for all kind of images, that's not where "file type" would help. The file "kind", as shown in the Finder, would be more appropriate. However, Mac OS's fast search function that I use in FAF does not know the kind at that deep level where it searches.

Hence, all you can do is to perform multiple searches for all the kinds of extensions that meet your "image file" criteria, unfortunately.

I guess Spotlight would be a better help here, as it's suited for categorizing file types the way you need it. Maybe have a look at "HoudahSpot" and "Tempo". Both build on Spotlight, i.e. with the same limitations, but provide a better way to search than Spotlight.

If you want to try out FAF's file type support, simply drag a "sample" file, i.e. an image file, into the File Type field - if that kind of file supports file types, its 4-letter code will be filled in. Then you can search for that, finding all other files of that type, no matter what their extension is.

Wish I could offer a more helpful way to find all those images, but that's where we're hitting the limits of what FAF can do based on what the OS offers.

I could, but that would add potential for much slower searches. The purpose of this tool is to use a special Mac OS function to search an entire volume very fast. Find Any File's speed relies on that OS function. The OS function only supports a limited amount of search criteria - pretty much just those that Find Any File offers you. Adding any "smarter" search criteria would require to make assumptions that may backfire, making the search inefficient and slow. Thus I find it best to stay with the OS function's limitations so that we're always getting a predictably fast search.

Version 1.5, however, comes a little closer to this: Now you can have multiple name criteria. They all must be met to find a file, though. There is still no "or" search feature.

The root mode is mainly useful when the Mac has multiple user accounts configured and you like to find files in every user's private folders. Without the root mode, you won't get to look at other users' files.

If you're the only user on the computer, then using the root search mode is hardly ever necessary, as whilst Mac OS X does protect quite a few system files, it doesn't usually hide them from view. However, there may be software that hides files on purpose from you, and that's where the root mode might help you reveal those items, too.

That gives me an idea - I should add a search criteria to list only items that are usually hidden from your view.

Yes, version 1.5 now has this feature. Simply drop the folder to search onto the menu where you can select where to search.

However, keep in mind that, contrary to popular belief, it may not be faster. If you have a lot of files in that specific folder, then a full search over the entire volume such as Find Any File does it, may still be faster than a recursive search in a large folder. And the problem is that Find Any File cannot predict beforehand how large and deep the folder is. To be on the safe side, it prefers the somewhat fast "entire volume" search instead of running into the situation where it'll search a deep folder recursively which then may take 10 times longer than the entire volume search.

To accomodate browsing the desired folders, I have added the hierarchical results view in which you can get to the folder of your interest almost as easily.

Yes, that's the funny part about it: Mac OS provides such a "fast search over entire volume" function since its HFS beginnings, i.e. for over 15 years, and it was used by Apple's own "Find File" and "Sherlock" in previous OS versions. Yet, when these apps were replaced by Spotlight, several other programmers tried to fill in the gap, but apparently all of them missed to use this special function. I couldn't believe it - that function was well documented, yet none of the new tools would use it even if these tools searched the entire volume, an example being the quite popular EasyFind. This annoyed me so much that, after waiting for a few years for others to "get it", I released my own tool using this feature. And guess what - two days after releasing FAF, someone else released a similar app (Find File), using the same fast search function. Go figure.

Update: EasyFind finally also uses the fast search feature where appropriate. Now we have more choices again. I recommend to take a look at it, as it does a few nice tricks Find Any File doesn't.

That'd be any local (i.e. internal and directly attached) disk with a HFS(+) format, also called "Mac OS Extended", and network disks that are using the "AFP" protocol and are using the HFS(+) format as well.
For example, most NAS units do not support AFP, and even if they do, they usually use a Linux server internally with a "Ext" volume format, which doesn't support fast search.
If you connect to a network volume served by another Mac, you'll usually get the fast search option.
In theory, other volume formats and network protocols could support fast search, too. For instance, the Joliet File System for Mac OS 7-9 I wrote long ago did support this on CD-ROMs formatted in ISO 9660 and Joliet format.
And NTFS would be suited for this as well due to the way its directory is stored in one large "file" (in the "$MFT"), just like the so-called catalog file in HFS. It's all a question of writing the additional code for OS X disk drivers and implementing, in case of network storage (NAS), the AFP protocol fully. But who'd pay for that? I could do it, if you paid me. Will cost a bit, though. :)