Hmmmm.....  My setup seems to be eating some messages between 1:343/41 and
1:343/40....  Or, I didn't catch this one on 1:343/40.....  Need to look
closer.  I believe BinkD is *not* properly handling failures on writing (or
renaming) files when received.....

 BS>> Did anyone of you notice that the CVS version of maximus segfaults?

 BJ> Do you mean when running with a telnet port?  Or via the local
 BJ> console (with the -k option)?

 BS> With the telnet port.

Ok.  The telnet port broke on my system a few weeks ago.  I think Wes made
a check in of some code related to getting serial / modem support, but I
haven't dug into the logs enough to make sure of my suspision.  I'll have
to try your suggested roll back to see if it clears up the problem here. 
'bin/max -k' is running ok on 1:343/40.  The runbbs.sh script (using
telnet) bombs out on 1:343/40 like I believe it is / was doing on your
system....

 BJ> I've known that the telnet port broke a bit ago, but hadn't figured
 BJ> out why or spent time on it.  I figured Wes did an update and
 BJ> figured when he got the modem code cleaned up, it would be
 BJ> fixed....  I'm ok running console mode, but some keys (such as
 BJ> control-z, usually usesd to save a message in the full screen
 BJ> editor) are trapped by the command shell and sent as signals to the
 BJ> program....  

 BS> Yes, but it's good that we can solve it :)

 BS>> To solve it, you can use the libcompat.so and 
 BS>> libcomm.so from the max-3.03b release.

I need to dig that stuff out and see what the differences are.  Yesterday I
tried to find my oldest uncompressed copy, but it looked like it didn't go
back far enough.....  Thanks for the note....  I need to give your fix a
try.

 BJ> Ah...  I'll have to take a look....  Thanks for the info..... 

 BS> :-) Maybe we could put the old version on CVS, so 
 BS> people can get something there _works_.

Yes!  Since the .so files are generated by the make files, we need to track
it back to which source files changed, check in the bad code as a branch,
and re-check in the good code on the main line.  I won't get to this
today.....

 BS> Or make 2 modules, max-unstable and max-stable.. 
 BS> Unstable could be a playground, while stable, should 
 BS> contain a stable branch..

Modules?  I believe you mean branches in the CVS tree.  Yes, we need to
branch the CVS tree and have a stable (root) branch, and an unstable branch
for dealing with code changes till we can get new code better tested.  I'd
have to read over the CVS documentation to see how to do this, but I
suspect it is just a matter of running cvs with a specific flag option and
setting a label on each branch that stays on the "tip" of the
branch, like RCS did things.

Take care.....

Bob Jones, 1:343/41


--- Maximus/2 3.01