Event ID source incorrect for BIND 8.2.3 NT port

Joe Rhett jrhett at isite.net
Thu Apr 26 23:20:38 UTC 2001


> This turns out to be a minor problem with named-xfer stripping out the path
> name using the Unix separator '/' character. On NT this is '\'. This has to be
> done so that it doesn't break the Unix side. It's in common code.

Since I have no NT development environment, would someone be willing to add
this fix?

>> 2. Is there any reason why the BINDCtrl program isn't a Control Panel applet?

> If you don't want that modify BINDInstallDlg.cpp to not install a 
> program group.
 
> >Second, even if it is a command line interface there's no reason not to
> >build a Control Panel applet to invoke it.
> 
>          Feel free to contribute this to the code base. 
 
You know, replying to me to say that someone needs to do it is about as
useful as just plain 'yep'. In my original query I specifically asked if
someone with an NT development environment would be willing to make these
changes. If I could do this, I would. I have contributed changes before, I
got the concept. I just don't have a build environment for this.

> >Your questions make no sense to me. The reload button should be equivalent
> >to "ndc reload". The restart button should be the same as "ndc restart". If
> >you're not sure what the difference is between these functions, why are you
> >replying?
> 
> I know what the difference is. The question is why do you want to restart
> BIND instead of reloading it.  What do you gain from doing this?  Do people have
> a hard time pressing two buttons instead of one? The underlying code would
> have to invoke the stop command to the system service and then the start
> command in the system service.  There's no restart system service command.
 
You clearly don't know what the difference is. "reload" looks for changes 
to zone files.  "restart" dumps the cache and reloads named.conf. Two 
very different operations.

>          If your goal is to reduce memory BIND's memory consumption, you're
> on the wrong track.  BIND caches information in memory about previous queries
> so reduce the need to rerequest an answer that it's already received.

Where did that come from? This is the 'workers' list. We all understand the
idea of a cache. Can you stop the 'dumb boy' responses?

Sorry if it wasn't clear - I figured I didn't have to cover the obvious on
the workers list. I know everything that BIND is capable of, I know how to
configure it. I'm asking if someone is willing to produce patches to
resolve issues in the current config.

-- 
Joe Rhett                                         Chief Technology Officer
JRhett at ISite.Net                                      ISite Services, Inc.

PGP keys and contact information:          http://www.noc.isite.net/Staff/


More information about the bind-workers mailing list