Provided by: dcc-server_1.2.74-2_i386 bug


     dblist - Database List Distributed Checksum Clearinghouse


     dblist [-vVHD] [-G on | off] [-h homedir] [-C type h1 h2 h3 h4]
            [-I server-ID] [-A dbaddr] [-L pathlen] [-P pages] [-T timestamp]
            [file1 file2 ...]


     Dblist lists the contents of a DCC database as it does some consistency

     -v   lists more of the database.  Additional information is produced with
          additional -v arguments.

     -V   displays the version of the DCC database lister.

     -H   turns off the listing of the hash table as well as the analysis of
          the hash table.  Determining the worst case and average lengths of
          chains in the hash table can take a long time for a large database
          on a small computer.

     -D   turns off the listing of the data or checksum records.

     -G on
          lists a greylist database.

     -h homedir
          overrides the default DCC home directory, which is often /var/dcc.

     -C type h1 h2 h3 h4
          limits the listing to records containing that checksum or one of the
          other checksums specified with -C or server-IDs specified with -I.
          As many as 16 checksums can be specified.

     -I server-ID
          limits the listing to records with that server-ID or one of the
          other server-IDs specified with -I or checksums specified with -C.
          As many as 16 server-IDs can be specified.

     -A dbaddr
          excludes database records before dbaddr.

     -L pathlen
          excludes records with path lengths shorter than pathlen.

     -P pages
          ignores all but the last pages of the database.

     -T timetamp
          excludes records with other timestamps.  As many as 16 timestamps
          can be specified.

     file1 file2 ...
          are names of databases to be listed.  The default is dcc_db and its
          companion, dcc_db.hash in the DCC home directory.

     By default, the sizes of the main file and the hash table as well as how
     much they contain and values related to the performance of the hash are

     With a single -v, most of the mail database file and the contents of
     memory mapped server flooding positions in the file  are listed.
     The listing starts with the serial number of the database file which is
     when old entries were last removed from it by dbclean(8) That is followed
     by similar lines showing the oldest timestamp of checksums not expired by
     dbclean and of mail that is not "spam."

     The flooding positions from the file are record offsets or
     addresses in the main database file.

     A typical record in the main database file looks like:

     02/07/02 20:25:12.497032    5    auth 1601              2fe5b94
          path: 103<-101<-1601
       Body      6       e2d3f96a c65aea01 3fece361 edff9ecf  2f21364 772d2
       Fuz1      many    6ff56fe8 ffc312d7 a5fe8f13 12a537ae  2f21364 200a9
       Fuz2      many    fac882b8 03eea34f bd792c40 2fe6fd54  2f21364 72816

     That example was received by a DCC server with server-ID 1601 at about
     8:25 GMT on the evening of February 7, 2000.  The report was about a mail
     message set to 5 addressees.  The report was from a client that presented
     a client-ID and matching password that the server recognized or
     authenticated.  The report was then sent or ‘flooded’ to the server with
     server-ID 101 which in turn sent it to a server with server-ID 103.  That
     server sent it to the local DCC server.  The record is at the address
     0x2fe5b94 in the database.  The record contains 3 checksums.  The simple
     checksum of the body of the message was e2d3f96a c65aea01 3fece361
     edff9ecf The total number of recipients of messages with this body
     checksum known in the database is 6, which implies this checksum had been
     previously reported with a target count of 1.  The previous report in the
     database of a message with this body checksum is at 0x2f21364.  The hash
     table entry for this body checksum is at 0x772d2.  This report included
     two fuzzy checksums.  Both have been previously reported as having been
     sent to many targets.

     An asterisk (*) before the name of the checksum would indicate that a
     later record in the database makes this checksum redundant.  A report of
     many addressees makes all preceding reports redundant.

     The string trimmed after the server-ID marks older reports that have had
     uninteresting checksums removed.  The string compressed after the server-
     ID would indicate that this older report has been trimmed and compressed
     with older reports.

     With two -v arguments, records added to the database by dbclean(8) from
     the server whitelist are also displayed.

     Three -v arguments cause the hash table to be displayed.  Three typical
     hash table entries look like:

           19b8:   19ee   19b7
           19b9:   19c0      0    90120 Fuz1
           19ba:      0      0  1b72300 Fuz1

     The entry in slot number 0x19b8 is unused or free.  Slot number 0x19b9 is
     the start of a chain of collisions or entries with the same hash value of
     0x19b9.  The next slot in this chain is at 0x19c0.  The corresponding
      checksum is at 0x9012 in the database.  The third slot at 0x19ba is also
     that of a Fuz1 checksum, but it is not part of a hash chain and its
     database record is at 0x1b72300.


     /var/dcc     is the DCC home directory containing data and control files.
     dcc_db grey_dcc_db
                  main file of checksums.
     dcc_db.hash grey_dcc_db.hash
                  database hash table.
                  memory mapped flooding positions.


     cdcc(8), dcc(8), dbclean(8), dccd(8), dccifd(8), dccm(8), dccproc(8).


     Implementation of dblist was started at Rhyolite Software in 2000.  This
     describes version 1.2.74.