How to look for files on your system very quickly

UPDATED with additional information.

This guide will work for most Unix-like operating systems. A lot of people probably know about this or similar approaches, but many new users don't.
If you have a Unix-like OS with a Desktop Environment, you probably search for files on your system or in storage by using a file manager's search tool (inputting something into the find field in dolphin/nemo/thunar/caja etc). If you have many files, such a search could take a lot of time to complete and find what you want, dozens of minutes in some cases. For example, I have caja on my GhostBSD and it can take forever to look for something on a multi-terabyte drive.
On systems without a Desktop Environment people usually look for files with find. For example: find /bin -name dd

There is a much more efficient way to look for files by employing a list/database of contents on your file system and checking it instead.

On FreeBSD the locate command does this (suggested by T-Daemon). A database of files is created and periodically updated on FreeBSD and locate command goes through this database looking for files. It is pre-installed on the stock FreeBSD. If you have a fresh install, when inputting locate BSD you'd receive a message:

locate: the locate database 'var/db/locate.database' is smaller than 256 bytes large.
To create a new database, please run the following command as root:
/etc/periodic/weekly/310.locate


After database creation you can search for files containing e.g. "BSD" in their names with locate BSD. The command is case-sensitive.

locate might not be flexible enough for some users. For example, if you have many external drives which you mount and dismount frequently, they might not get into the locate's periods of updates and sometimes it is more comfortable to manually create individual file/contents lists for the drives so that locate would not try to update them when there is no need (this could take a lot of time for voluminous drives and create unnecessary reads while not adding new information). If you periodically run FreeBSD from RAM for short times (by using GhostBSD, for example), there would be no databases on the operating system.
Furthermore, locate only shows file names with their paths, it does not show additional information like file size or modification date, and it does not show directories.
locate might also not index all the files on the system/storage because of access issues (not having enough privileges), as was noted by bob2112.

You can create your own lists of contents with find and then look for contents in it with grep, grep usually takes mere seconds to complete even on file lists weighting hundreds megabytes (in my personal experience). The only drawback is that the initial list creating using find command takes time, but you need to do this only once or once in a while to keep the file list updated (this can be done manually or automated with a script to update periodically; since I update manually, I do not have scripts to share at the moment). The initial file creation process shouldn't take longer than a regular search using the file manager and you won't need to bother your drives with find requests anymore.
You can create a list which would include files' and directories' names, modification dates and sizes with the following command (tested on FreeBSD 15.1 and GhostBSD 26.1; they should also work on Linux):
find path-to-directory-where-you'd-like-to-look-for-files -printf "%t %s %p\n" > contents
To list only files:
find path-to-directory-where-you'd-like-to-look-for-files -type f -printf "%t %s %p\n" > files
Then if you want to find files containing "BSD" in their names, simply run
grep BSD files
It should be noted that grep is a very versatile command and there are many ways to tweak the search queries to get more exact search results.
Please note that the basic grep command is case-sensitive!
find command can also be tweaked in various ways to add the file/directory information you'd expect to look for in contents lists.
You can also exclude paths when using find, for example:
find / -path "/home" -prune -o -path "/media" -prune -o -type f -printf "%t %s %p\n" > system_files

If you would go with creating your own contents lists you could disable locate altogether by running the following command as root as suggested by me12345 on GhostBSD forum:
chmod -x /etc/periodic/weekly/310.locate

Commands for older versions of FreeBSD:
find path-to-directory-where-you'd-like-to-look-for-files | xargs stat -f "%Sa %z %N" > contents
find path-to-directory-where-you'd-like-to-look-for-files -type f | xargs stat -f "%Sa %z %N" > files
grep BSD files
find / -path "/home" -prune -type f -o -path "/media" -prune -type f -o -type f | xargs stat -f "%Sa %z %N" > system_files
 
Last edited:
Code:
$ uname -rs
FreeBSD 14.4-RELEASE-p9
$ find $HOME -name .profile -printf "%t %s %p\n"
find: -printf: unknown primary or operator
FreeBSD is not Linux...
 
Regarding "How to look for files on your system very quickly", FreeBSD has a locate(1) facility to "locate" files from a created file database instantaneously, basically what you are proposing with your custom aproache.

The database is recreated on a weekly basis (see /etc/crontab), but one can change the frequency or which file systems, directories should be searched.

Besides the manual, see also:

/etc/periodic/weekly/310.locate
/etc/locate.rc
/etc/defaults/periodic.conf
 
The locate database is built by an unprivileged user, so it wont see user files without lax directory permissions. It also can't see files on encrypted home directories that aren't mounted at the time the weekly periodic task runs. I did, for a short time, have a separate locate database under ~/ but it didn't get much use because locate often isn't good enough for user files IMO.

I find that find(1) is fast enough these days with my current hardware. A few years ago a simple name search took ~15min cold and 10s warm, but with 16GB the cache didn't stay warm for long. I added a small micromanaged SATA L2ARC which brought the cold time down to ~30s. I now have 64GB and L2ARC on NVMe and searches are about 2s.
 
Windows is constantly indexing files to the detriment of performance.

I have it disabled and wrote my own.
That's kind of the problem with any indexing system. Eventually, your "I need performance NOW!!!" is gonna be buggered by a background scan kicking off at the inopportune time. I prefer to understand the "standard" filesystem layout and expect categorized files to be in specific areas, then do a limited find to locate things.

However, don't want to rain on OPs parade and if someone prefers file indexing then so be it.
 
'Locate' just gives another option, from 'find'. Of course neither of them are perfect.

I remember years ago, windows used to slow to a crawl when the virus scanner kicked in... 😄
 
That's kind of the problem with any indexing system. Eventually, your "I need performance NOW!!!" is gonna be buggered by a background scan kicking off at the inopportune time.
Yep, sometimes there are knobs that you can tune it with, like "don't index this device or those directories". Should the OS directories be indexed? How about a device that has SQL databases? I think indexing is more useful when it's done on user data stuff, like say pictures, music or documents.
 
A downside of locate(1) for anyone shutting down their computer when finished the day's jobs (or to go sleep) and startup on starting next day's job (or woke up) would be the database is NEVER updated.
This is because updates for locate(1) database is a nightly jobs and the computer is in power-off state when the update jobs should run.
 
A downside of locate(1) for anyone shutting down their computer when finished the day's jobs (or to go sleep) and startup on starting next day's job (or woke up) would be the database is NEVER updated.
This is because updates for locate(1) database is a nightly jobs and the computer is in power-off state when the update jobs should run.
You can just run anacron.
 
Back
Top