Just a sample of the Echomail archive
Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.
|    JAMNNTPD    |    Support for the JAMNNTPD software client    |    2,630 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 255 of 2,630    |
|    mark lewis to Scott Street    |
|    xlat bug?    |
|    25 Jun 12 18:57:26    |
      > I bet. UTF-8 support -- for writing -- was added more or less in        > the last minute, before Johan disappeared from fidonet and left us all       > alone with his babies.               SS> Is that to say, that JamNNTPd needs a maintainer?              i cannot speak to that but if someone is rooting around in the code and can       provide easy patches to those of us who compile our own, well ;)              speaking of which, my system has numerous background processes that access my       JAMbases at any time... someone needs to look in jamnntpd and see where it       emits these and fix the problem...               Could not read messagebase header of               the JAM specs say to lock a specific byte in the header file but i seem to       recall that at least one library (MKMSG written in PASCAL) doesn't lock that       byte but another... AIR, the thought with this library is that byte/region       level locking may not be available but you can't get a lock on a file if any       part of the file is locked...              [time passes]              after digging for a while, i finally found some original JAM sources from the       JAM gods... it seems that the first byte is the lock byte after all... unless       i'm counting incorrectly and it is the second byte...              in any case, this is a bug and there needs to be some sort of timing loop that       retries the lock when it is needed or at least retries access if there is a       lock preventing reading... i would say, without looking at the nntp RFC, that       this lock needs to be at least 30 to 60 seconds in length... i'm guessing on       those time lengths based on how long it make take for comms to be seen as       failed over the 'net... FTP, for example, has something like a 5 or 10 minute       timeout...              i am not using the SMAPI stuff but the original stuff... there were things in       SMAPI that i didn't like way back and i've never used it with my JAMbases...       somethings are just enough slightly different to cause problems from expected       actions :?              )\/(ark               * Origin: (1:3634/12)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca