|This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)|
- lets you find files by name without going through your filesystem
- ...from an index typically rebuilt every night ( )
- of the (GNU, slocate, mlocate) set, you probably want mlocate
- you probably have mlocate
- will be symlinked to mlocate/slocate if you use them
(part of GNU findutils)
slocate and mlocate
(s for secure, m for merging)
Additionally stores file permissions and ownership (at scan time), and the slocate/mlocate commands will filter out entries that the invoking user couldn't read.
mlocate's functionally extends slocate, in that its updatedb only rereads a directory contents if that directory's mtime changed, which often avoids stat()ing most files.
Hooks into the kernel: file creation is recorded, this list is dumped to a database daily.
Its locate searches both the database and kernel list, so you'll always see new files within ~2 seconds of their creation.
Builds its own kernel module (that hooks into link, mkdir, mknod, open, rename and symlink).
Can be told not look in / not index certain places.
Details vary slightly between implementations, but most support at least:
- don't go under certain under absolute paths
- will not add its content, but still enter the directory name itself
- avoid trailing slashes
- don't index certain filesystem types
mlocate/slocate add stuff, including:
- directory basename
- e.g. .git .bzr .hg .svn, because their existance may be interesting but their filenames not so much
security notesHistorical/GNU locate would let you see filenames that you couldn't yourself.
slocate/mlocate hide filenames the calling user couldn't read, by checking the permission they also store in the database. (note that this means that the database itself should be readable by locate but not the calling user, which is why there is usually an mlocate/slocate user/group and the locate command uses SUID)
Keep in mind that indexed permissions can be a day behind, so if you want more security (at the cost of more IO on every locate), you can make updatedb store a flag into the database that means "locate should stat() the parent directories to see if the calling user could list this(verify)". (note: the check is disabled if the file is world-readable)
The database may be in one of various places, depending on which one you use.
Perhaps the simplest summary comes from
Which in my case says something like:
Database /var/lib/mlocate/mlocate.db: 552,900 directories 5,639,641 files 428,849,911 bytes in file names 181,205,838 bytes used to store database
...yes, that 5+ million files and I need to clean up:P though the database is only ~170MB.
Listing all entries could be done like
sudo locate /
...but keep in mind that if the security flag mentioned above applies, it means access() calls for everything.