s4: Patch for "libnet/libnet_samsync_ldb.c"
jelmer at samba.org
Thu Dec 16 03:09:44 MST 2010
On Thu, 2010-12-16 at 10:09 +0100, Matthias Dieter Wallnöfer wrote:
> it's problematic since these "samdb_msg_*" calls are in use by some LDB
> modules (rootdse, samldb, instancetype) and these expect to have LDAP
> error codes returned.
> For callers beside these it could make sense that the result code is
> changed to NTSTATUS since they itself often return exactly this type.
> All in all I don't think that it's clear which solution is better than
> the other one, but I've thought about another idea: in
> "ldb_msg_add_value" we make also use of the "errno" variable if we run
> into a OOM. What would be if we enhance this and use it for
> distinguishing between a generic and a OOM error in the LDAP error ->
> NTSTATUS mapping function?
That makes life a fair bit more complicated for the callers, because
they would have to check not one but two variables.
I wonder if it makes sense to add a specific OOM error code to LDB?
> Jelmer Vernooij wrote:
> > On Sat, 2010-12-11 at 12:01 +0100, Matthias Dieter Wallnöfer wrote:
> >> Jelmer Vernooij wrote:
> >>> On Tue, 2010-12-07 at 15:44 +0100, Matthias Dieter Wallnöfer wrote:
> >>>> Regarding the other return values beside ERR_OPERATIONS_ERROR for out of
> >>>> memory it's not so easy. Caller functions differ in behaviour regarding
> >>>> NTSTATUS results - so I really thought it only to be used by msg_add*
> >>>> calls and not for "ldb_add", "ldb_modify" ecc.
> >>> Considering that, perhaps it would make more sense for the
> >>> samdb_msg_add_* functions to return a NTSTATUS value directly?
> >> then we cannot use them in the LDB modules anymore. Do you have another
> >> proposal?
> > which LDB modules do you mean specifically, and why can't we use them
> > there anymore?
> > Cheers,
> > Jelmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: This is a digitally signed message part
More information about the samba-technical