On Wed, 17 Apr 2002, Tim Potter wrote:
> On Wed, Apr 17, 2002 at 09:15:44AM +0200, Rafal Szczesniak wrote:
>
> > > All the rpc client routines send the request and receive the reply,
> > > returning any useful data to the caller. If any subsequent calls are
> > > required it's up to the caller
On Wed, Apr 17, 2002 at 09:38:23AM +0200, Jean Francois Micouleau wrote:
> > get it right if I try to explain it. The entire buffer is always sent
> > across the wire, even in the request when it isn't actually needed
> > probably due to a bug in the IDL file.
>
> it's not a bug. the buffer is
On Wed, 17 Apr 2002, Tim Potter wrote:
> In the spoolss stuff you make a subsequent call 100% of the time. (-:
>
> It's more a matter of flexibility. I'm trying to keep these libraries
> as simple as possible by design.
it's also a matter of keeping the layers separated and clear and clean.
On Wed, Apr 17, 2002 at 09:15:44AM +0200, Rafal Szczesniak wrote:
> > All the rpc client routines send the request and receive the reply,
> > returning any useful data to the caller. If any subsequent calls are
> > required it's up to the caller to do this.
>
> Hmmm, you're right, but subsequ
On Wed, 17 Apr 2002, Rafal Szczesniak wrote:
> On Wed, 17 Apr 2002, Tim Potter wrote:
>
> > All the rpc client routines send the request and receive the reply,
> > returning any useful data to the caller. If any subsequent calls are
> > required it's up to the caller to do this.
>
> Hmmm, you'
On Wed, 17 Apr 2002, Tim Potter wrote:
> On Tue, Apr 16, 2002 at 02:52:01PM +0200, Rafal Szczesniak wrote:
>
> > proper args to continue or finish the enumeration. It may be annoying to
> > write such code in each place we use client side of enumeration, so I
> > propose to write a "higher level
On Tue, Apr 16, 2002 at 02:52:01PM +0200, Rafal Szczesniak wrote:
> proper args to continue or finish the enumeration. It may be annoying to
> write such code in each place we use client side of enumeration, so I
> propose to write a "higher level" function which could take care of doing
> it pro
On Sun, 14 Apr 2002, Andrew Bartlett wrote:
> I would expect the current code comes pretty close already actually.
>
> I'll be interested to see what you actually need to change.
OK. This is another fix to enumerationn code. Major changes:
- fix for returned error codes during enumeration
- c
Rafal Szczesniak wrote:
>
> On Sun, 14 Apr 2002, Andrew Bartlett wrote:
>
> > Rafal Szczesniak wrote:
> > >
> > > > is now in the tree. In particular
> > > > this version works with NT4.
> > >
> > > That one I sent did not ? I've tried it and it was fine.
> >
> > It had my NT4 box in a spin as
On Sun, 14 Apr 2002, Andrew Bartlett wrote:
> Rafal Szczesniak wrote:
> >
> > On Sun, 14 Apr 2002, Andrew Bartlett wrote:
> >
> > > Rafal Szczesniak wrote:
> > > >
> > > > Here's the patch that adds server side of lsa_enum_trust_dom call to
> > > > samba. Memory leak causing segfault to smbd in
Rafal Szczesniak wrote:
>
> On Sun, 14 Apr 2002, Andrew Bartlett wrote:
>
> > Rafal Szczesniak wrote:
> > >
> > > Here's the patch that adds server side of lsa_enum_trust_dom call to
> > > samba. Memory leak causing segfault to smbd in some cases is already
> > > fixed. Major changes include:
>
On Sun, 14 Apr 2002, Andrew Bartlett wrote:
> Rafal Szczesniak wrote:
> >
> > Here's the patch that adds server side of lsa_enum_trust_dom call to
> > samba. Memory leak causing segfault to smbd in some cases is already
> > fixed. Major changes include:
>
> That code (with some major changes)
Rafal Szczesniak wrote:
>
> Here's the patch that adds server side of lsa_enum_trust_dom call to
> samba. Memory leak causing segfault to smbd in some cases is already
> fixed. Major changes include:
That code (with some major changes) is now in the tree. In particular
this version works with N
Here's the patch that adds server side of lsa_enum_trust_dom call to
samba. Memory leak causing segfault to smbd in some cases is already
fixed. Major changes include:
1. tdb_search_keys() is the new utility function searching the keys that
match given pattern. (tdbutil.c and tdbutil.h)
2.
14 matches
Mail list logo