DB5.3_DUMP(1)

πŸ’Ύ db5.3_dump β€” the manual, but make it cute ✨

okay bestie, you found db5.3_dump in the manual pages (section 1, general commands, if we're being official about it) and honestly? she's iconic. let's get into it πŸ’…


✨ NAME ✨

db5.3_dump β€” write database to flat-text format 🫢


πŸ¦‹ SYNOPSIS πŸ¦‹

db5.3_dump [-klNpRrV] [-d ahr] [-f output] [-h home] [-P password] [-s database] file

🌸 DESCRIPTION 🌸

so basically, db5.3_dump reads the database file file and writes it out to standard output using a portable flat-text format β€” the same format that db5.3_load understands, so the two of them are literally a matching set, no cap.

and the file argument? it has to be a file that was produced using the Berkeley DB library functions. not just any random file you found. the vibe check is strict on that one πŸŽ€


πŸ’– OPTIONS πŸ’–

  • -d β€” dump the specified database in a format that's helpful for debugging the Berkeley DB library routines. it takes one of these letters:
    • a β€” display all information.
    • h β€” display only page headers.
    • r β€” do not display the free-list or the pages on the free list. this mode is the one the recovery tests use.
⚠️ the output format of the -d option is not standard and may change, without notice, between releases of the Berkeley DB library. so don't go building your whole personality on parsing it, bestie 😭
  • -f β€” write to the specified file instead of to standard output. redirect, but make it official.
  • -h β€” specify a home directory for the database environment. by default, the current working directory is used.
  • -k β€” dump record numbers from Queue and Recno databases as keys. yes queen, give us those numbers as keys.
  • -l β€” list the databases stored in the file. just a little peek at what's inside πŸ‘€
  • -N β€” do not acquire shared region mutexes while running. other problems, like potentially fatal errors in Berkeley DB, will be ignored as well.
🚨 this option is intended only for debugging errors, and should not be used under any other circumstances. like, any. fr fr. put it down.
  • -P β€” specify an environment password. and now the serious part: although Berkeley DB utilities overwrite password strings as soon as possible, be aware there may be a window of vulnerability on systems where unprivileged users can see command-line arguments, or where utilities aren't able to overwrite the memory containing the command-line arguments. keep that in mind, babe πŸ’œ
  • -p β€” if characters in either the key or data items are printing characters (as defined by isprint(3)), use printing characters in file to represent them. this one is a gift because it permits users to use standard text editors and tools to modify the contents of databases. slay.
πŸ“Œ note: different systems may have different notions about what characters are considered printing characters, and databases dumped in this manner may be less portable to external systems. so cute but maybe don't travel with it.
  • -R β€” aggressively salvage data from a possibly corrupt file. the -R flag differs from the -r option in that it will return all possible data from the file, at the risk of also returning already deleted or otherwise nonsensical items. data dumped in this fashion will almost certainly have to be edited by hand or by other means before the data is ready for reload into another database.
  • -r β€” salvage data from a possibly corrupt file. when used on an uncorrupted database, this option should return equivalent data to a normal dump, but most likely in a different order. same energy, shuffled ✨
  • -s β€” specify a single database to dump. if no database is specified, all databases in the database file are dumped.
  • -V β€” write the library version number to standard output, and exit. short, sweet, informative.

okay now the fine print, and it's important so read it with me 🫢

dumping and reloading Hash databases that use user-defined hash functions will result in new databases that use the default hash function. although using the default hash function may not be optimal for the new database, it will continue to work correctly. so like, not perfect, but she survives πŸ’…

dumping and reloading Btree databases that use user-defined prefix or comparison functions will result in new databases that use the default prefix and comparison functions. and in this case, it is quite likely that the database will be damaged beyond repair, permitting neither record storage nor retrieval. πŸ’€ yeah. that one's rough.

the only available workaround for either case is to modify the sources for the db5.3_load utility to load the database using the correct hash, prefix, and comparison functions. that's the whole workaround. that's it. no magic flag.

the db5.3_dump utility output format is documented in the Dump Output Formats section of the Berkeley DB Reference Guide, if you want the full lore.

the db5.3_dump utility may be used with a Berkeley DB environment (as described for the -h option, the environment variable DB_HOME, or because the utility was run in a directory containing a Berkeley DB environment). in order to avoid environment corruption when using a Berkeley DB environment, db5.3_dump should always be given the chance to detach from the environment and exit gracefully. to cause db5.3_dump to release all environment resources and exit cleanly, send it an interrupt signal (SIGINT). let her leave the party politely, okay? 😌

even when using a Berkeley DB database environment, the db5.3_dump utility does not use any kind of database locking if it is invoked with the -d, -R, or -r arguments. if used with one of these arguments, the db5.3_dump utility may only be safely run on databases that are not being modified by any other process; otherwise, the output may be corrupt. no locking, no protection, no chill 🚨

and the exit status, because we love closure: the db5.3_dump utility exits 0 on success, and >0 if an error occurs.


🌈 ENVIRONMENT 🌈

  • DB_HOME β€” if the -h option is not specified and the environment variable DB_HOME is set, it is used as the path of the database home, as described in DB_ENV->open. your home away from home 🏠

πŸ‘‘ AUTHORS πŸ‘‘

Sleepycat Software, Inc. 🐱 this manual page was created based on the HTML documentation for db_dump from Sleepycat, by Thijs Kinkhorst <thijs@kinkhorst.com>, for the Debian system (but may be used by others). giving credit where credit is due, always πŸ’œ


and that's the whole page, bestie! this one's from the DB5.3_DUMP(1) manual, dated 28 January 2005 β€” vintage but still serving 🌸 go dump something responsibly, and don't touch -N unless you're literally debugging. periodt πŸ’…βœ¨