LOCATEDB(5)

๐Ÿ’พ LOCATEDB โ€” like, the whole entire tea on file name databases โœจ

okay bestie, sit down, grab a boba, because we're about to talk about locatedb โ€” the front-compressed file name database format, which is genuinely one of those things that sounds boring until you realize it's the whole reason locate is fast ๐Ÿ’…


๐ŸŒธ NAME ๐ŸŒธ

locatedb โ€” front-compressed file name database ๐Ÿ—‚๏ธโœจ


๐Ÿซถ DESCRIPTION ๐Ÿซถ

So this page is documenting the format of file name databases for the GNU version of locate. And like, what even is a file name database? It's literally a list of files that were in certain directory trees at the moment the databases were last updated. A lil snapshot. A time capsule. ๐Ÿ“ธ

And here's the thing โ€” there can be multiple databases, not just one. Users get to pick which databases locate searches by using an environment variable or a command line option; go look at locate(1) for that. Meanwhile the system administrator is the one who picks the file name of the default database, how often the databases get updated, and which directories they hold entries for. Normally, file name databases are updated by running the updatedb program on a schedule โ€” typically nightly. See updatedb(1) if you wanna go deeper ๐Ÿ‘‘


โœจ GNU LOCATE02 database format โœจ

This one is the default format of databases produced by updatedb, so it's the main character here, no contest. The updatedb program runs frcode to compress the list of file names using front-compression, which reduces the database size by a factor of 4 to 5. Four to five!! that's not a glow-up, that's a transformation ๐Ÿ˜ญ

Front-compression (also known as incremental encoding) works like this:

The database entries are a sorted list โ€” sorted case-insensitively, for users' convenience ๐Ÿ’–. And since the list is sorted, each entry is likely to share a prefix (that's an initial string, bestie) with the previous entry. So:

  • Each database entry begins with a signed offset-differential count byte. That byte is the additional number of characters of prefix of the preceding entry to use beyond the number that the preceding entry is using of its predecessor. (And yes, the counts can be negative. slay.)
  • Following that count is a null-terminated ASCII remainder โ€” the part of the name that comes after the shared prefix.

Now, if the offset-differential count is bigger than what fits in a signed byte (ยฑ127), then the byte gets the value 0x80 (binary 10000000) and the actual count follows in a 2-byte word, with the high byte first (network byte order). That count can also be negative, with the sign bit living in the first of the two bytes. iykyk ๐Ÿค“

Every database starts with a dummy entry for a file called LOCATE02, and locate checks for that to make sure the database file has the right format. It ignores the entry when doing the search. It's basically a vibe check for the file. โœ…

And now the part that ruins lives:

Databases cannot be concatenated together, even if the first (dummy) entry is trimmed from all but the first database. Why? Because the offset-differential count in the first entry of the second and following databases will be wrong. ๐Ÿ˜ญ so don't do it. don't be that person.

Also, a lil heads up about the future: in the future, the data within the locate database may not be sorted in any particular order. So if you want sorted results, pipe the output of locate through sort -f. periodt ๐Ÿ’…


๐Ÿฆ‹ slocate database format ๐Ÿฆ‹

The slocate program uses a database format that's similar to, but not quite the same as, GNU locate. Not the same!! don't mix them up bestie.

  • The first byte of the database specifies its security level.
  • If the security level is 0, slocate will read, match and print filenames on the basis of the information in the database only.
  • But if the security level byte is 1, slocate omits entries from its output if the invoking user is unable to access them. ๐Ÿ”’
  • The second byte of the database is zero.
  • The second byte is followed by the first database entry.
  • The first entry in the database is not preceded by any differential count or dummy entry. Instead, the differential count for the first item is assumed to be zero.

Starting with the second entry (if there is one) in the database, the data is interpreted the same way as for the GNU LOCATE02 format. ๐ŸŒˆ


๐ŸŽ€ Old Locate Database format ๐ŸŽ€

okay so there's also an old database format, used by Unix locate and find programs and by earlier releases of the GNU ones. vintage! antique! doesn't text back! ๐Ÿ•ฐ๏ธ

updatedb runs programs called bigram and code to produce old-format databases. The old format differs from the description above in these ways:

  • Instead of each entry starting with an offset-differential count byte and ending with a null, byte values from 0 through 28 indicate offset-differential counts from -14 through 14.
  • The byte value indicating that a long offset-differential count follows is 0x1e (30), not 0x80.
  • The long counts are stored in host byte order, which is not necessarily network byte order, and in host integer word size, which is usually 4 bytes.
  • They also represent a count 14 less than their value.
  • The database lines have no termination byte; the start of the next line is indicated by its first byte having a value โ‰ค 30.

And there's more, bestie:

In addition, instead of starting with a dummy entry, the old database format starts with a 256 byte table containing the 128 most common bigrams in the file list.

A bigram is a pair of adjacent bytes. Bytes in the database that have the high bit set are indexes (with the high bit cleared) into the bigram table. Immaculate data structure design โœจ

The bigram and offset-differential count coding makes these databases 20โ€“25% smaller than the new formatโ€ฆ but it makes them not 8-bit clean ๐Ÿ˜ญ. Any byte in a file name that falls in the ranges used for the special codes gets replaced in the database by a question mark โ€” which, not coincidentally, is the shell wildcard that matches a single character. ๐Ÿ’€ the drama!


๐Ÿ”ฅ EXAMPLE ๐Ÿ”ฅ

Input to frcode:

/usr/src
/usr/src/cmd/aardvark.c
/usr/src/cmd/armadillo.c
/usr/tmp/zoo

Length of the longest prefix of the preceding entry to share:

0 /usr/src
8 /cmd/aardvark.c
14 rmadillo.c
5 tmp/zoo

Output from frcode, with trailing nulls changed to newlines and count bytes made printable:

0 LOCATE02
0 /usr/src
8 /cmd/aardvark.c
6 rmadillo.c
-9 tmp/zoo

(6 = 14 - 8, and -9 = 5 - 14) โ€” see?? THE MATH IS MATHING ๐Ÿงฎ๐Ÿ’…


๐Ÿ˜ญ REPORTING BUGS ๐Ÿ˜ญ

okay if something's broken, tell the people, they wanna know:

Report any other issue via the form at the GNU Savannah bug tracker:

<https://savannah.gnu.org/bugs/?group=findutils>

General topics about the GNU findutils package are discussed at the bug-findutils mailing list:

<https://lists.gnu.org/mailman/listinfo/bug-findutils>

Copyright ยฉ 1994โ€“2026 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.

This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. (no warranty bestie, it's giving "as-is" ๐Ÿ™ˆ)


๐ŸŒˆ SEE ALSO ๐ŸŒˆ

Full documentation <https://www.gnu.org/software/findutils/locatedb> or available locally via: info locatedb


that's the whole page bestie, you're officially fluent in locatedb ๐Ÿ’– this was findutils, dated 2020-12-27, and honestly? iconic of them. go forth and locate things ๐Ÿฆ‹โœจ๐ŸŽ€

๐Ÿ“ฆ where this page comes from