dbd — CNID database maintanance
dbd can dump, scan, reindex and rebuild Netatalk dbd CNID databases. It must be run with appropiate permissions i.e. as root.
Dump CNID database. With -i dump indexes
too.
Scan volume:
Compare CNIDs in database with volume
Test if .AppleDouble directories exist
Test if AppleDouble files exist
Report orphaned AppleDouble files
Report directories inside .AppleDouble directories
Check name encoding by roundtripping, log on error
Check for orphaned CNIDs in database (requires
-e)
Open and close adouble files
-c Don't check .AppleDouble stuff, only
check orphaned.
-n Don't open CNID database, skip CNID
checks, only traverse filesystem
Rebuild volume. With -f wipe database and
rebuild from CNIIDs stored in AppleDouble files.
Sync CNIDSs from database with volume
Ensure .AppleDouble directories exist
Ensure AppleDouble files exist
Delete orphaned AppleDouble files
Report directories inside .AppleDouble directories
Check name encoding by roundtripping, log on error
Delete orphaned CNIDs in database (requires
-e)
Open and close adouble files
-c Don't create .AppleDouble stuff, only
cleanup orphaned.
-f Wipe database and rebuild from IDs
stored in AppleDouble files, only available for volumes
without nocnidcache option. Implies
-e.
Prepare upgrade:
Before installing an upgraded version of Netatalk that is linked against a newer BerkeleyDB lib, run `dbd -u ...` from the OLD Netatalk pior to upgrading on all volumes. This removes the BerkleyDB environment. On exit cnid_dbd does this automatically, so normally calling dbd -u should not be necessary !
Only work on inactive volumes and lock them (exclusive)
Rebuild indexes (just for completeness, mostly useless!)
verbose
In order to be able to run -rf reconstructing the
CNIDs in the database from the AppleDouble files,
make sure you've run a -r rebuild sometimes before, where
the CNIDs then would have been synched between database and
AppleDouble files.
Also be careful about the option nocnidcache. Avoid
this option if at all possible, because if prevents you from being able to
use -f.
The CNID backends maintains name to ID mappings. If you change a filename outside afpd(8) (shell, samba), the CNID db will not know and not reflect that change. Netatalk tries to recover from such inconsistencies as gracefully as possible. The mechanisms to resolve such inconsistencies may fail sometimes, though, as this is not an easy task to accomplish. E.g. if several names in the path to the file or directory have changed, things may go wrong.
If you change a lot of filenames at once, chances are higher that the afpds fallback mechanisms fail, i.e. files will be assigned new IDs, even though the file hasn't changed.
