if one by accident points the ldbsearch command to any file, which is not a ldb file, this file is silently converted to a tdb file ;-) . root@dc0:~# file /tmp/t2.ldif /tmp/t2.ldif: ASCII text root@dc0:~# ldbsearch -H /tmp/t2.ldif # returned 0 records # 0 entries # 0 referrals root@dc0:~# file /tmp/t2.ldif /tmp/t2.ldif: TDB database version 6, little-endian hash size 10000 bytes This behaviour my be OK for ldbadd/ldbmodify. But for a search command? Samba version is: Version 4.1.11-Debian
This behavior MAY only be "ok" if the file is empty (zero length). Even then, I would say the behavior is HIGHLY questionable. What if the file was a damaged LDB? The operation will just destroy it completely. If a file format can't be read, the application MUST throw an exception. Not silently destroy the data.
Note: ldbsearch is part of Samba, not TDB! This seems to have been fixed at some point. In a testenv: $ cp COPYING /tmp/ $ bin/ldbsearch -H /tmp/COPYING Unable to open tdb '/tmp/COPYING': Input/output error Failed to connect to '/tmp/COPYING' with backend 'tdb': Unable to open tdb '/tmp/COPYING': Input/output error Failed to connect to /tmp/COPYING - Unable to open tdb '/tmp/COPYING': Input/output error $ diff /tmp/COPYING COPYING $ whereas a proper ldb-tdb gives expected results. $ cp st/ad_dc/private/wins_config.ldb /tmp/ $ bin/ldbsearch -H /tmp/wins_config.ldb # record 1 dn: name=TORTURE_11,CN=PARTNERS address: 10.53.57.11 name: TORTURE_11 objectClass: wreplPartner pullInterval: 0 pushChangeCount: 0 type: 0x3 distinguishedName: name=TORTURE_11,CN=PARTNERS # returned 1 records # 1 entries # 0 referrals $ diff /tmp/wins_config.ldb st/ad_dc/private/wins_config.ldb $
This was fixed by 35f92b82b5e919a2736aec8560ea9c4c7dc4bb7a in March 2017.