BS> Hello Bob!

Hello, Bo...  Sorry for the delay in response....  I'm dealing with a
neighbor who had a stroke and has a disabled son.....  (along with my
parents).....  Free time will be short thru the end of the month....

 BS> Mon 2003-08-18 13:52, Bob Jones (1:343/41) wrote to Bo Simonsen:

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

 BS> Just a problem i thought of.. if the reciever system 
 BS> isn't tossing regulary, and squish calls the packages 
 BS> the same filename, what is the mailer supposed to do?

The standard file names I'm using shouldn't overwrite until the eighth day.
 And even then, squish should only be adding to existing archives, the way
I'm set up....  I suspect I have a mailer on 1:343/41 still configured to
send 1:343/40 to 1:343/41 or something like that, or maybe a squish
configuration file burried some place (for daily or weekly cleanup) that
still hasn't had the 1:343/41 vs 1:343/40 nodes seperated since at one
point the two nodes had been merged together in the past.....  There may
also be a "point" issue, due to how I've also used some point
numbers for cross connecting the two systems before merging the two nodes
in the past.....  And now I'm trying to break back to using the two node
numbers on seperate machines.....  I just need time to look for the issue. 
This just impact the experimental machine for now....

 BS> Maybe squish should use sprintf(arcname, "%08x.%s", 
 BS> time(NULL), ...); for arcmail filenames..

No reason to change from the existing standard .... at least not yet....

 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.

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

 BS> I bet it's the same, if you run max -w what's happingen then?

I get a setmentation fault when using the -w switch on my current version
under linux.  It's been a few weeks since I've update code from CVS....

 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....  

 BS> Let's hope so!

 BJ>> 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> Hmm.. i didn't tested the editor in local mode.. Local 
 BS> mode is a bit wierd, because i only see monocrome 
 BS> colors.. maybe my config is wrong? 

Yes, I'm seeing monochrome on local mode also.  I haven't investigated why,
but I'm sure it is due to how the console is emulated.....

 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.

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

 BS> Okey :)

 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_.

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

Nor have I had the time the last few weeks, or the next few weeks.  :( 
Hopefully I'll use this message as a reminder when I get some free time....

 BS> It would be good if we could solve the code problem 
 BS> smoothly, because wes added alots.

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

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

 BS> Nope 'cvs -d ... co module', that's what a mean, a new module..

Ok.  I'll have to read the documentation on this.  Why do I get a feeling
that this involves storing two copies of the source tree in CVS?  If that's
the case, we will need to make sure the version numbers are different on
the two different trees so we can tell the files apart.....

Take care.....

Bob Jones, 1:343/41


--- Maximus/2 3.01