Seth Woolley's Man Viewer

locatedb(5) - locatedb, locatedb - front-compressed file name database - man 5 locatedb

([section] manual, -k keyword, -K [section] search, -f whatis)
man plain no title

LOCATEDB(5)                                                        LOCATEDB(5)



NAME
       locatedb - front-compressed file(1,n) name database

DESCRIPTION
       This  manual  page  documents the format of file(1,n) name databases for the
       GNU version(1,3,5) of locate.  The file(1,n) name databases contain lists of  files
       that  were  in(1,8)  particular directory trees when the databases were last
       updated.

       There can be multiple databases.   Users  can  select(2,7,2 select_tut)  which  databases
       locate  searches  using an environment variable or command line option;
       see locate(1).  The system administrator can choose the  file(1,n)  name  of
       the  default  database,  the  frequency  with  which  the databases are
       updated, and the directories for which they contain entries.  Normally,
       file(1,n) name databases are updated by running the updatedb program period-
       ically, typically nightly; see updatedb(1).

       updatedb runs a program called frcode to  compress  the  list  of  file(1,n)
       names  using  front-compression,  which  reduces the database size by a
       factor(1,6) of 4 to 5.  Front-compression (also known as incremental  encod-
       ing(3,n)) works as follows.

       The  database entries are a sorted list (case-insensitively, for users(1,5)'
       convenience).  Since the list is sorted, each entry is likely to  share
       a prefix (initial string(3,n)) with the previous entry.  Each database entry
       begins with an offset-differential count byte, which 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.   (The
       counts  can  be  negative.)   Following  the count is a null-terminated
       ASCII remainder -- the part of the name that follows the shared prefix.

       If the offset-differential count is larger than can be stored in(1,8) a byte
       (+/-127), the byte has the value 0x80 and the count follows in(1,8) a 2-byte
       word, with the high byte first (network byte order).

       Every  database begins with a dummy entry for a file(1,n) called `LOCATE02',
       which locate checks for to ensure that the database file(1,n) has  the  cor-
       rect format; it ignores the entry in(1,8) doing the search.

       Databases  can  not be concatenated together, even if(3,n) the first (dummy)
       entry is trimmed from all but the first database.  This is because  the
       offset-differential  count in(1,8) the first entry of the second and follow-
       ing databases will be wrong.

       There is also an old database format, used by Unix locate and find pro-
       grams  and  earlier  releases  of the GNU ones.  updatedb runs programs
       called bigram and code to produce old-format databases.  The old format
       differs  from  the above description in(1,8) the following 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 off-
       set-differential count follows is 0x1e (30), not 0x80.  The long counts
       are stored in(1,8) host(1,5) byte order, which is not  necessarily  network  byte
       order, and host(1,5) integer word size, which is usually 4 bytes.  They also
       represent a count 14 less(1,3) 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.

       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(1,8) the file(1,n) list.  A bigram is a pair of adjacent bytes.  Bytes
       in(1,8)  the  database that have the high bit set(7,n,1 builtins) are indexes (with the high
       bit cleared) into the bigram table.  The bigram and offset-differential
       count  coding makes these databases 20-25% smaller than the new format,
       but makes them not 8-bit clean.  Any byte in(1,8) a file(1,n) name that is in(1,8) the
       ranges  used  for  the  special  codes is replaced in(1,8) the database by a
       question mark, which not coincidentally is the shell wildcard to  match
       a single character.

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 ALSO
       find(1), locate(1), locatedb(5), xargs(1)  Finding  Files  (on-line  in(1,8)
       Info, or printed)

BUGS
       The  best  way  to  report  a  bug  is to use the form at http://savan-
       nah.gnu.org/bugs/?group=findutils.  The reason for  this  is  that  you
       will then be able to track progress in(1,8) fixing the problem.   Other com-
       ments about locate(1) and about the findutils package in(1,8) general can be
       sent  to  the bug-findutils mailing list.  To join(1,n) the list, send(2,n) email
       to bug-findutils-request@gnu.org.



                                                                   LOCATEDB(5)

References for this manual (incoming links)