IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This reverts commit fafb8ad2b81b9a46cf8259bedc1dca5023b06115.
This fix is not valid:
1. convert_string() is not only used for key strings but also for data.
2. Some databases use string_tdb_data() i.e. non-null-terminated strings
as keynames and others (like the one I was using), use
string_term_tdb_data(), i.e. zero-terminated key strings.
After discussion with Metze, the easiest (and proper way) to
handle this is to specify key names as "keyname\0" for databases
which use string_term_tdb_data().
Sorry for the noise...
Michael
(This used to be commit 17c012c4645f4e9542537c15f80d9b4e74304d11)
This prevented all commands operating on keys (all non-traverse commands)
in tdbtool to fail with a "fetch failed" or "delete failed" message.
It seems that it fixes bug #2344 ...
Apparently this bug was introduced with 94e53472666ed in 2005.
Either nobody is using tdbtool or else tdb_find() has become
more strict about the key legth in the meantime. :-)
Michael
(This used to be commit fafb8ad2b81b9a46cf8259bedc1dca5023b06115)
Calling tdb_traverse inside a transaction led to the transaction lock being
held indefinitely. This was caused by the tdb_transaction_lock/unlock inside
tdb_traverse: The transaction code holds the global lock at offset
TRANSACTION_LOCK. The call to tdb_transaction_lock does nothing because the
transaction_lock is already being held. tdb_transaction_unlock inside tdb_wrap
resets tdb->have_transaction_lock but does not release the kernel-level fcntl
lock. transaction_commit later on does not release that fcntl lock either,
because tdb->have_transaction_lock was already reset by tdb_transaction().
This patch does fix that problem for me. An alternative would be to make
tdb->have_transaction_lock a counter that can cope with proper nesting, maybe
in other places as well.
Volker
(This used to be commit 89543005fe2e4934b3c560c937d49304a32a7fc2)
Never install generated prototype files. It's easier to break the
API when using them and they're not easily readable for 3rd party users.
Conflicts:
source/auth/config.mk
source/auth/credentials/config.mk
source/auth/gensec/config.mk
source/build/smb_build/config_mk.pm
source/build/smb_build/main.pl
source/build/smb_build/makefile.pm
source/dsdb/config.mk
source/lib/charset/config.mk
source/lib/tdr/config.mk
source/lib/util/config.mk
source/libcli/config.mk
source/libcli/ldap/config.mk
source/librpc/config.mk
source/param/config.mk
source/rpc_server/config.mk
source/torture/config.mk
(This used to be commit 6c659689ed4081f1d7a6253c538c7f01784197ba)
use shared library versions if they are provided by the system.
This puts talloc and tdb in a similar situation as popt:
the system version is used if provided but if it's not there or if it
is too old, we use our internal version statically.
(This used to be commit 86f88eb7b51377344eebf0b6fabad0f5459b3f45)
