https://gitlab.synchro.net/main/sbbs/-/commit/dbf0a87ad95f01a4f88a324d
Modified Files:
src/sbbs3/main.cpp
Log Message:
Clear mouse hot spots (if any) before hanging up.<nelgin> Ah, here's a good one. If I ssh to my bbs server, then ssh to my bbs, do whatever then /O to logout, when I left click in the putty window I get "0;98;20M0;98;20m and stuff like that. I have to run reset to get it working properly.
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/b269b65ad5d09814abbbff51
Modified Files:
src/sbbs3/main.cpp
Log Message:
Refactor timed-event and QWKnet call-out schedulingReduced probably the biggest if() conditionals in sbbs to a single line by breaking the "time to run" logic into separate functions and sharing those functions between both QWKnet and timed-event scheduling. There was no actual problem with this code/logic, it was just very difficult to read and understand and step-through with a debugger and understand why or why not an event might run under different configurations and circumstances.Also removed the PostLink network call-out logic. pnet.dab is no longer read and written-to and if you happened to have any PostLink hubs configured (how?!?), they'll no longer be "polled". This is the only functional change unless I did something wrong in the process.One thing I noticed and contemplated, the current time is not queried between consecutive timed-event scheduling/execution. It's possible that an executed event can take a long time and impact the criteria for the next timed event. The events are checked for scheduling every few seconds, so I can't really think of a big down-side to the current design (apparently intended to reduce unnecessary querying of the current date/time), so I didn't do anything to change that. Just something I noticed.
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/eb4fa76ca9635a48ea2c103f
Modified Files:
src/sbbs3/main.cpp
Log Message:
Delete dead codeCID 174474
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/80de2727ae620ef4e770c3c6
Modified Files:
src/sbbs3/main.cpp
Log Message:
Lower the "SSH session establishment failed" log msg levelfrom NOTICE to INFO, per Nelgin
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/b9e78bdf93e4d9b3e7608e4d
Modified Files:
src/sbbs3/main.cpp
Log Message:
Batch download queue not cleared upon packed QWK packetBefore the "new filebase" merge of 2021, a user's batch download queue would be cleared when a QWK packet was successfully packed for them via the event thread (i.e. triggered via semaphore file). That was lost in the new filebase change (the batch download queue would not be cleared) - caught by Coverity (CID 350336).It appears pre-packed QWK packets never cleared the batch download queue (does anyone actually use this feature in this day and age?) - fixed.
--- SBBSecho 3.15-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/eb7e6bbfaa15e42dc18239b3
Modified Files:
src/sbbs3/main.cpp
Log Message:
Fix CID 174378: Argument cannot be negative
--- SBBSecho 3.15-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/570f6f5ebcdb52a8c359dfc8
Modified Files:
src/sbbs3/main.cpp
Log Message:
Fix CID 319133: Unchecked return value
--- SBBSecho 3.15-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/141112e104ee22552140d82f
Modified Files:
src/sbbs3/main.cpp
Log Message:
Lower level of new "Logoff time <= logon time" log message... from ERROR to WARNING, but log the human-readable logon time too.This condition can easily happen if the system clock is corrected (e.g. a few seconds via NTP adjustment) during a quick connect/disconnect.Don't call logoffstats() unless a user actually successfully logged-in. I don't think sysops actually want all the time bots sit at the logon prompt counted as "time online" in their stats anyway.
--- SBBSecho 3.15-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/3ff572429ea30b11fb33d6b1
Modified Files:
src/sbbs3/main.cpp
Log Message:
When auto-deleting inactive users, log their real name too.
--- SBBSecho 3.15-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/cfd62425cd0c93e927989897
Modified Files:
src/sbbs3/main.cpp
Log Message:
Address new GCC warning instance
--- SBBSecho 3.15-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/f4b595c0a4726853510a083c
Modified Files:
src/sbbs3/main.cpp
Log Message:
Truncate node.dab to correct size when initializing any sbbs_t instanceFixes issue #395
--- SBBSecho 3.15-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/d2acbe52c3615ab8bfb45837
Modified Files:
src/sbbs3/main.cpp
Log Message:
Eliminate newly-unused variable: addr_strFixes issue #421
--- SBBSecho 3.15-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/b91acb61c474ed71a1fa3a2e
Modified Files:
src/sbbs3/main.cpp
Log Message:
Fix crash when cleanup() was called twice in a row, e.g. load_cfg failureNeed to nullify the xpms after destroying/freeing (as is done in otherservers already).
--- SBBSecho 3.15-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/d1f4767a9597b659d7996e83
Modified Files:
src/sbbs3/main.cpp
Log Message:
Correct node number *always* before clearning NODE_RRUN [R] status flagIf nodeX/node.cnf has the wrong node number, the [R] flag would be cleared fromthe wrong node upon automatic configuration reload. This likely fixes the issue that Keyop is reporting in #synchronet
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/56d1e7fe4b3c6bf6176e4406
Modified Files:
src/sbbs3/main.cpp
Log Message:
Output snappiness improvements.When the system checks for an incoming byte, if there's any pendingoutput, send it immediately, bypassing the outbuf highwater mark.This allows the final non-full packet to be sent without waitingfor the OutbufDrainTimeout (default 10ms), and makes a big differencewhen doing a large number of ANSI queries (send an ANSI code, waitfor a response). There's a small but noticable placebo effect aswell that makes everything feel smoother.This commit also cleans up the output thread where it pulls fromthe ring buffer into the linear buffer to take advantage of the newevent-based ring buffers. Much easier to read now.Speaking of easier to read, this also includes some whitespacefixups.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/fe78b9895edde6d8217c2dc1
Modified Files:
src/sbbs3/main.cpp
Log Message:
Call RingBufRead() when avail == 0 to reset eventsIf something else sets these events, and they never get cleared,this will fall into a tight loop.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/e379967ced1c8dc936090ff2
Modified Files:
src/sbbs3/main.cpp
Log Message:
Move some lines around to clamp sbbs->outbuf.highwater_mark at IO_THREAD_BUF_SIZE
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/dfc4e9320299020943ea640c
Modified Files:
src/sbbs3/main.cpp
Log Message:
Eliminate the global 'sbbs' here, was masking bugsI'm not sure what purpose this global variable once had, but it wasn't needednow and it was masking copy/paste issues in some of the sbbs_t methods in thisfile. Just make an 'sbbs' local to bbs_thread(), since there's where it'slegit-used.FYI: All the Cryptlib-SSH macros assume there's an 'sbbs' in scope.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/993518491b6ec81ed2a83151
Modified Files:
src/sbbs3/main.cpp
Log Message:
Fix gcc warnings in previous commit: don't bother with [s]size_t here
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/d1e32893f4adc36ed88f69a0
Modified Files:
src/sbbs3/main.cpp
Log Message:
Lower log level of send_telnet_cmd() send failure (to debug level)As apparently these happen a lot when a client disconnects rightaway after connecting.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/2eea219da85b0b8e205900ba
Modified Files:
src/sbbs3/main.cpp
Log Message:
Clean-up the logging around the auto-tuned outbuf highwater mark
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/f169a52fa7454842a6540423
Modified Files:
src/sbbs3/main.cpp
Log Message:
Remove accidentally added debug line with no effect.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/fec7f7de961c102b4052e255
Modified Files:
src/sbbs3/main.cpp
Log Message:
Include time used (HH:MM:SS) in node#/laston mqtt msg
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/6426954c87ae1bd5c04691e4
Modified Files:
src/sbbs3/main.cpp
Log Message:
Don't attempt to remove a non-existing qwk-pack semfileReduce occurrences of subsequent errors (unsure of root-cause):!ERROR 2 (No such file or directory) in main.cpp line 2778 (event_thread) removing "/sbbs/data/pack0341.now"This does seem to be the only location that deleted pack*.now files, so weird that they'd disappear sometime after calling glob(), but I do understand that its theoretically possible.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/5f7f1104db341b7c52e4e209
Modified Files:
src/sbbs3/main.cpp
Log Message:
Don't try to upgrade */csts.dab and */dsts.dab files that don't existIn a fresh v3.20 install, the legacy stats files don't exist, so don't tryto convert/upgrade them and log errors about it.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/d60262aa81e4b14405e6fd57
Modified Files:
src/sbbs3/main.cpp
Log Message:
Lower severity of "Spy socket ... connected" log message from ERR (?) to INFOLooks like just a confluence of search/replace errors over the past 19 years,starting with commit 9ef382e50c6.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/95a07b236294a36633481033
Modified Files:
src/sbbs3/main.cpp
Log Message:
Fix crash when getting file area web_file_prefix in JSexecjs_init was assuming that startup != NULL
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/9eeb09f19514e1ccf10d85eb
Modified Files:
src/sbbs3/main.cpp
Log Message:
Fix PETSCII 40/80 column port connections for IPv6The connected TCP port detection method only worked for IPv4, so automaticallydetecting a CBM/PETSCII connection over IPv6 didn't work. Thanks to Deuce'sxp_sockaddr and helper functions, this was an easy change.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/d6544a7700951590fa2916a4
Modified Files:
src/sbbs3/main.cpp
Log Message:
Enforce telbuf size bounds (don't just log the overflow condition)This should resolve CID 453850
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/ca7ab040466b030281a9aaca
Modified Files:
src/sbbs3/main.cpp
Log Message:
Add a 60-second timeout to sbbs_t::passthru_socket_activate()Keyop reported an issue via irc whereby a user that failed to download a filewould leave the node "hung" in "downloading via telnet" node status eventhough the user had long since disconnected and the log reflected that theterminal server was aware of this:term Node 4 <user> sexyz: !1152 zmodem_recv_raw TIMEOUT (10 seconds)term Node 4 <user> sexyz: !zmodem_recv_header TIMEOUTterm Node 4 <user> external Timeout waiting for output buffer to empty<minutes later>term Node 4 connection reset by peer on sendterm Node 4 !ERROR 32 sending on socket 102term Node 4 !ERROR 32 sending on socket 102term Node 4 !ERROR 32 sending on socket 102term Node 4 !ERROR 32 sending on socket 102term Node 4 !ERROR 32 sending on socket 102term Node 4 disconnectedterm Node 4 !ERROR 32 sending on socket 102andterm Node 3 <user> sexyz: !1152 zmodem_recv_raw TIMEOUT (10 seconds)term Node 3 <user> sexyz: !zmodem_recv_header TIMEOUTterm Node 3 <user> sexyz: !Receive timeout (1 seconds)term Node 3 <user> sexyz: !Receive timeout (1 seconds)term Node 3 <user> sexyz: !Receive timeout (1 seconds)term Node 3 <user> sexyz: !Receive timeout (1 seconds)term Node 3 <user> sexyz: !Receive timeout (1 seconds)term Node 3 <user> sexyz: !Receive timeout (1 seconds)term Node 3 <user> sexyz: !Receive timeout (1 seconds)term Node 3 <user> sexyz: !Receive timeout (1 seconds)term Node 3 <user> sexyz: !Receive timeout (1 seconds)term Node 3 <user> sexyz: !Receive timeout (1 seconds)term Node 3 <user> sexyz: !1152 zmodem_recv_raw TIMEOUT (10 seconds)term Node 3 <user> sexyz: !zmodem_recv_header TIMEOUTterm Node 3 <user> external Timeout waiting for output buffer to empty<minutes later>term Node 3 connection reset by peer on receiveterm Node 3 !ERROR 32 sending on socket 96These nodes were then locked up in call to passthru_socket_activate(false)as reported by gdb, e.g.Looking at passthru_socket_activate(), the deactivation path (called at theend of external() in this case), it was clear that this could be an infiniteloop in the case the user had disconnected: do { // Allow time for the passthru_thread to move any pending socket data to the outbuf SLEEP(100); // Before the node_thread starts sending its own data to the outbuf } while(RingBufFull(&outbuf));These flush/purge loops aren't strictly needed if the user has disconnected,but as can be seen by the above logs, the terminal server may not know that(the socket may not indicate disconnect) before passthru_socket_activate()is called by external().So... worst case, just do the activation and deactivation buffer flushesand purges for 60 seconds.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/23cd780b3dc51f1d55398748
Modified Files:
src/sbbs3/main.cpp
Log Message:
Remove redundant timestamp from "End of preexisting log entry" log messageMost logs sysops are looking at already have a date/timestamp for eachmessage, so this one ended up with 3 date/timestamps in a single line.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/e5f64faf337040f12844c4cc
Modified Files:
src/sbbs3/main.cpp
Log Message:
Log a critical error message if a node is WFC, but its socket is still in useThis should avoid/work-around issue #630Nelgin's terminal server log indicated that the node's configuration was beingreloaded for a new client connection (which doesn't normally/always happen,only when there's been a config file change or a node "rerun" requested),while there was still a user online using that node. This would explain thesegfault (configuration fields being freed and reallocated).The node_socket[] array indicates when a node thread is actively servicinga client, so it should contain INVALID_SOCKET for the any node's that WFC.If it doesn't, that means something/someone changed the node's status valueto 0 (WFC) in the node.dab file while the node was still in-use. Let's notcrash in this case and rather just log the message and give the client thenext available node (if any).
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/229cca918d31e14add4b2ef7
Modified Files:
src/sbbs3/main.cpp
Log Message:
Close node socket after waiting one hour to go inactive to run exclusive event

After 90 minutes of waiting, we'll do the same abort wait (and run the event anyway), but closing the node's socket should be enough to get the node_thread to terminate and set the node status back to NODE_WFC.

Apparently some sysops like to leave their terminals idling (e.g. running MRC) and never disconnect and since they're T-exempt, the BBS won't limit their
time online to allow events to run. Exclusive events will wait for all nodes
to become inactive, but give up after 90 minutes of waiting and run the event anyway and set node status to WFC at the end. If the node was actually still connected/in-use, this could lead to the (new) critical error messages logged "!Node X status is WFC, but the node socket (N) and thread are still in use!" and other chaos (NODE STATUS FIXUP and the like).

This should prevent all that by just abruptly disconnecting the node after waiting 60 minutes for the sysop to gracefully disconnect. The log message
when this happens:
"!TIRED of waiting for node N to become inactive (status=X), closing socket Y" --- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/6b49ddffc9b3ee4bb3bdb3c1
Modified Files:
src/sbbs3/main.cpp
Log Message:
Auto-recycle the term server if/when the ctrl/text.ini file is created/touched --- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 main.cpp 1.775 1.776
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv18524

Modified Files:
main.cpp
Log Message:
This change goes with the previous commit to scfglib2.c (with no commit msg): Address problem reported by Mark Lewis:
If a timed event is configured to both run "exclusively" and on "Any" node, then any nodes in use at the time of the event would get their status changed to waiting-for-connection (WFC) and it could actually become possible for 2 clients to be using the same node number.
So, when loading the configuration, turn off the "exclusive" flag if the event's node is set to "Any" (0).
Just for completeness, fix the actual bug (introduced in main.cpp 1.744) too.


--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 main.cpp 1.757 1.758
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv22730

Modified Files:
main.cpp
Log Message:
Accept and store the "Internet host number" portion of the telnet
TERMINAL LOCATION NUMBER (RFC 946) in sbbs_t::telnet_location.

Some (older?) versions of fTelnet request to send this option to the BBS to share the real IP address of the client. Accept this option (when using
"format 0") and store the first 32-bits (an IPv4 address) in the telnet location storage / caller-ID information. The same place the telnet
SEND LOCATION value is stored if received.

Now, we're not requesting this option (e.g. with a Telnet "DO" command), but fTelnet doesn't need that: It offers to send it, so we accept.


--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 main.cpp 1.760 1.761
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv12091

Modified Files:
main.cpp
Log Message:
We need to expand telnet IACs contained in passthru socket data received from external programs (when in Telnet mode).


--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 main.cpp 1.763 1.764
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/home/rswindell/sbbs/src/sbbs3

Modified Files:
main.cpp
Log Message:
A couple of passthrough socket fixes:
1. when de-activating the passthru socket, give the passthru_thread some
cycles to copy any remaining socket data into the outbuf before we let
the node_thread continue on and spew its own data into the outbuf.
This fixes the problem of final messages of a file transfer protocol
being intermixed with BBS data (prompts, menus, and such) and causing
file download finalization issues.
2. Don't read from the passthru socket until there is enough room in the
outbuf for the maximum possible telnet-expanded read size. This fixes
streaming download protocol (ZMODEM and YMODEM-G) errors.

Also, for good measure, check the passthru_socket for writability before send()ing on it and log a warning if it's ever not writable.


--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 main.cpp 1.772 1.773
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv20280

Modified Files:
main.cpp
Log Message:
Don't try to remove a bad .QWK packet if it's been renamed to *.bad.


--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

El 28/8/19 a las 23:23, rswindell escribi≤:

src/sbbs3 main.cpp 1.772 1.773
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv20280

Modified Files:
main.cpp
Log Message:
Don't try to remove a bad .QWK packet if it's been renamed to *.bad.

---

i notice that have several *.bad packets at my data dir.


-rw------- 1 root root 6807 ago 16 03:47 VERT.qwk.5d5a512f.bad
-rw------- 1 root root 7898 ago 13 19:47 VERT.qwk.5d5a5944.bad
-rw------- 1 root root 7245 ago 14 14:47 VERT.qwk.5d5a59bc.bad

i rename to vert.qwk to reprocess it, and say that all message are dupe.
Then, i think that was process and import messages fine.

is this commit related to this issue?


Aug 29 10:24:45 localhost synchronet: evnt Inbound QWK Packet detected: /sbbs/data/VERT.qwk
Aug 29 10:24:45 localhost synchronet: evnt QNET Executing external:
unzip -o -j /sbbs/data/VERT.qwk * -d /sbbs/temp/event/
Aug 29 10:24:45 localhost synchronet: evnt QNET Reading /sbbs/temp/event/HEADERS.DAT
Aug 29 10:24:45 localhost synchronet: evnt QNET Reading /sbbs/temp/event/VOTING.DAT
Aug 29 10:24:45 localhost synchronet: evnt Importing QWK Network Packet: /sbbs/data/VERT.qwk
Aug 29 10:24:45 localhost synchronet: evnt Importing QWK messages from
VERT into DOVE-Net Synchronet Discussion
Aug 29 10:24:45 localhost synchronet: evnt QNET !smb_addmsg duplicate Message-ID: <5D564377.6017.sync@vert.synchro.net> found in message #36400
Aug 29 10:24:45 localhost synchronet: evnt QNET !smb_addmsg duplicate Message-ID: <5D563EDE.40572.dove_sync@digitaldistortionbbs.com> found in message #36401
Aug 29 10:24:45 localhost synchronet: evnt QNET !smb_addmsg duplicate Message-ID: <5D563EDE.40572.dove_sync@digitaldistortionbbs.com> found in message #36401
Aug 29 10:24:45 localhost synchronet: evnt QNET !smb_addmsg duplicate Message-ID: <5D564039.40573.dove_sync@digitaldistortionbbs.com> found in message #36402
Aug 29 10:24:45 localhost synchronet: evnt QNET !smb_addmsg duplicate Message-ID: <5D5633E8.3542.dove-syncdisc@bbs.leenooks.net> found in
message #36403
Aug 29 10:24:45 localhost synchronet: evnt QNET !smb_addmsg duplicate Message-ID: <5D564ECC.6022.sync@vert.synchro.net> found in message #36404
Aug 29 10:24:45 localhost synchronet: evnt Importing QWK messages from
VERT into DOVE-Net Synchronet Programming (C/C++ and CVS)
Aug 29 10:24:45 localhost synchronet: evnt QNET !smb_addmsg duplicate Message-ID: <5D56516D.39346.syncprog@cvsuser> found in message #21047
Aug 29 10:24:45 localhost synchronet: evnt Importing QWK messages from
VERT into DOVE-Net Synchronet Data
Aug 29 10:24:45 localhost synchronet: evnt QNET !smb_addmsg duplicate Message-ID: <5D564BFC.177089.syncdata@vert.synchro.net> found in message
#13539
Aug 29 10:24:45 localhost synchronet: evnt Finished Importing QWK
Network Packet from VERT: (0 msgs) in 1 seconds (0 msgs/sec), 1 errors,
8 dupes
Aug 29 10:24:45 localhost synchronet: evnt QNET /sbbs/data/VERT.qwk
renamed to /sbbs/data/VERT.qwk.5d67d21d.bad
Aug 29 10:24:45 localhost synchronet: evnt QNET !ERROR 2 (No such file
or directory) in main.cpp line 2876 (event_thread) removing "/sbbs/data/VERT.qwk" access=0



thanks!!

---
■ Synchronet ■ Dock Sud BBS TLD 24 HS - http://bbs.docksud.com.ar - telnet://bbs.docksud.com.ar
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Re: src/sbbs3/main.cpp
By: Ragnarok to rswindell on Thu Aug 29 2019 11:07 am

El 28/8/19 a las 23:23, rswindell escribi≤:

src/sbbs3 main.cpp 1.772 1.773
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv20280

Modified Files:
main.cpp
Log Message:
Don't try to remove a bad .QWK packet if it's been renamed to *.bad.

---

i notice that have several *.bad packets at my data dir.

-rw------- 1 root root 6807 ago 16 03:47 VERT.qwk.5d5a512f.bad -rw------- 1 root root 7898 ago 13 19:47 VERT.qwk.5d5a5944.bad -rw------- 1 root root 7245 ago 14 14:47 VERT.qwk.5d5a59bc.bad

i rename to vert.qwk to reprocess it, and say that all message are dupe. Then, i think that was process and import messages fine.

is this commit related to this issue?

The commit fixes this error:

Aug 29 10:24:45 localhost synchronet: evnt QNET !ERROR 2 (No such file
or directory) in main.cpp line 2876 (event_thread) removing "/sbbs/data/VERT.qwk" access=0

digital man

This Is Spinal Tap quote #37:
David St. Hubbins: We are Spinal Tap from the UK - you must be the USA!
Norco, CA WX: 92.1°F, 42.0% humidity, 4 mph NE wind, 0.00 inches rain/24hrs
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

i enable debug:, the "QWK vote failure, offset 6144 in
/sbbs/data/VERT.qwk" appear:


Aug 29 23:54:29 localhost synchronet: evnt Inbound QWK Packet detected: /sbbs/data/VERT.qwk
Aug 29 23:54:29 localhost synchronet: evnt QNET Executing external:
unzip -o -j /sbbs/data/VERT.qwk * -d /sbbs/temp/event/
Aug 29 23:54:29 localhost synchronet: evnt QNET Reading /sbbs/temp/event/HEADERS.DAT
Aug 29 23:54:29 localhost synchronet: evnt QNET Reading /sbbs/temp/event/VOTING.DAT
Aug 29 23:54:29 localhost synchronet: evnt Importing QWK Network Packet: /sbbs/data/VERT.qwk
Aug 29 23:54:29 localhost synchronet: evnt Importing QWK messages from
VERT into DOVE-Net Synchronet Discussion
Aug 29 23:54:29 localhost synchronet: evnt QNET !smb_addmsg duplicate Message-ID: <5D564377.6017.sync@vert.synchro.net> found in message #36400
Aug 29 23:54:29 localhost synchronet: evnt QNET !smb_addmsg duplicate Message-ID: <5D563EDE.40572.dove_sync@digitaldistortionbbs.com> found in message
#36401
Aug 29 23:54:29 localhost synchronet: evnt QNET !smb_addmsg duplicate Message-ID: <5D563EDE.40572.dove_sync@digitaldistortionbbs.com> found in message
#36401
Aug 29 23:54:29 localhost synchronet: evnt QNET !smb_addmsg duplicate Message-ID: <5D564039.40573.dove_sync@digitaldistortionbbs.com> found in message
#36402
Aug 29 23:54:29 localhost synchronet: evnt QNET !smb_addmsg duplicate Message-ID: <5D5633E8.3542.dove-syncdisc@bbs.leenooks.net> found in
message #364
03
Aug 29 23:54:29 localhost synchronet: evnt QNET !smb_addmsg duplicate Message-ID: <5D564ECC.6022.sync@vert.synchro.net> found in message #36404
Aug 29 23:54:29 localhost synchronet: evnt QNET Duplicate vote-msg from VERT Aug 29 23:54:29 localhost synchronet: evnt QNET QWK vote failure, offset
6144 in /sbbs/data/VERT.qwk
Aug 29 23:54:29 localhost synchronet: evnt Importing QWK messages from
VERT into DOVE-Net Synchronet Programming (C/C++ and CVS)
Aug 29 23:54:29 localhost synchronet: evnt QNET !smb_addmsg duplicate Message-ID: <5D56516D.39346.syncprog@cvsuser> found in message #21047
Aug 29 23:54:29 localhost synchronet: evnt Importing QWK messages from
VERT into DOVE-Net Synchronet Data
Aug 29 23:54:29 localhost synchronet: evnt QNET !smb_addmsg duplicate Message-ID: <5D564BFC.177089.syncdata@vert.synchro.net> found in message
#13539
Aug 29 23:54:29 localhost synchronet: evnt Finished Importing QWK
Network Packet from VERT: (0 msgs) in 1 seconds (0 msgs/sec), 1 errors,
8 dupes
Aug 29 23:54:29 localhost synchronet: evnt QNET /sbbs/data/VERT.qwk
renamed to /sbbs/data/VERT.qwk.5d688fe5.bad

---
■ Synchronet ■ Dock Sud BBS TLD 24 HS - http://bbs.docksud.com.ar - telnet://bbs.docksud.com.ar
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/230bd5872d55cb239b03aeed
Modified Files:
src/sbbs3/main.cpp
Log Message:
js_init() now logs notice-level messages upon runtime or context creation fail

js_init() failures are now logged with a critical error level (instead of just "error").
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/1994a535b8c0e688e8a139fc
Modified Files:
src/sbbs3/main.cpp
Log Message:
Don't log error on final channel message
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/7df6956da2b4246a9ca3940e
Modified Files:
src/sbbs3/main.cpp
Log Message:
Don't log an error if there's QWKnet sub pointer value to be read

This partially reverts commit 44c3350f where a bunch of read() and write() return value checking was added.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/bac2285755b0eda8a209e365
Modified Files:
src/sbbs3/main.cpp
Log Message:
Another fix for the read() reutrn value FORTIFY warning

that doesn't log an error
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/a8374b52cbc57902bb303d7e
Modified Files:
src/sbbs3/main.cpp
Log Message:
second part of commit 0b1b1a6f
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/e53f173153fdaf0341cca95c
Modified Files:
src/sbbs3/main.cpp
Log Message:
Remove unnecessary call to DuplicateHandle() in Win32 builds of sbbs_t::init()

The client_socket_dup is overwritten after with the return value of accept(), so this was likely a socket/handle leak (since commit 74470573, 17 years ago).

Noticed this only after logging a new error in an SSH connection when this
call to DuplicateHandle() failed for some reason (WinError 6), but it seems like it's been redundant code for a long time now. So just ace it and possibly fix a resource leak.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/346a2d304c7d921d656489ad
Modified Files:
src/sbbs3/main.cpp
Log Message:
Log the socket descriptor and protocol when getsockname() fails

This is a new error that just started cropping up. I suspect it's related to recent SSH changes. This might help a little with context, when it happens again.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/af7852df11093dc6ed559f64
Modified Files:
src/sbbs3/main.cpp
Log Message:
Ignore remove() return value purposefully in this case.

Does this resolve Coverity warning? I don't rember.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/2b2d8289b92d7f6e6faa1633
Modified Files:
src/sbbs3/main.cpp
Log Message:
More time_t printf fun.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/1e734d10425f7ca7fb239931
Modified Files:
src/sbbs3/main.cpp
Log Message:
Remove line that was commented-out 14 years ago

Commit d1182efc
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/0a6c1f00de9e4457f598b4f4
Modified Files:
src/sbbs3/main.cpp
Log Message:
Log a warning if failed to write to spy ring buffer
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/4fa2aa66fda6be0ef693f512
Modified Files:
src/sbbs3/main.cpp
Log Message:
Don't log an error if spy socket write return EPIPE (expected)

Also, resove a new gcc warning about signed/unsigned compares.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/a474017fb7c51f91ef9c4095
Modified Files:
src/sbbs3/main.cpp
Log Message:
sbbs_t::incom() should return NOINP immediately if/when socket disconnected

JS console.inkey() and friends use this as the underlying function to get
input from the TCP socket.

This might address issue #725

Hoping Nelgin will let us know.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/4c893720f8e0c57753b08a91
Modified Files:
src/sbbs3/main.cpp
Log Message:
Attempt to fix error nelgin reported with ssh session timeouts
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/e4adbcb541c6f7139e63d2ca
Modified Files:
src/sbbs3/main.cpp
Log Message:
Prevent the input thread from closing channel that has a session,
but does not yet have a session type.

Also, fix what appears to be a fairly blatant memory leak.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/346849ac253a08374b9bfca0
Modified Files:
src/sbbs3/main.cpp
Log Message:
Unlock ssh_mutex before calling sftps_recv()

This should fix the sftp hangs...
While FreeBSD will return EDEADLOCK when a mutex would deadlock,
Linux will do what I ask and deadlock.

Since we're not checking the return value of pthread_mutex_lock(),
this would go completely unnoticed on FreeBSD, resulting in the
mutex being unlocked early and all sorts of unprotected accesses
would happen, potentially doing crazy things. On Linux it just
deadlocks, and taking a peek at the thread backtraces makes the
problem obvious.

So, point to Linux for making life more correct for people who
do incorrect things (locking without checking the return value).

I'd also like to thank nelgin, for sticking with me on this issue
and being my gdb puppet.

And really, this commit should be shared by all the contributors
who... 𝆺𝅥𝅮𝆺𝅥𝅮𝆹𝅥𝅯𝆹𝅥𝅯
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/c846776318dc4ca28946083c
Modified Files:
src/sbbs3/main.cpp
Log Message:
Break stuff to test things.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/eddcfe2f9b10d250d16a6c7f
Modified Files:
src/sbbs3/main.cpp
Log Message:
Now unbreak!
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/be8603b11bd6cf12c6f74256
Modified Files:
src/sbbs3/main.cpp
Log Message:
Replace (and auto-upgrade) ctrl/time.dab with time.ini

This will allow us to change scfg_t.event[].last to a time_t value (from time32_t) whenever we abandon Borland C/C++ in the future.

Now it's trival for sysops to view/edit when their timed events 'last run' values. And there's no more endianness concerns. Bad .dab files, bad, go away.

After I wrote this change, I found the original conversion code in v4upgrade.c which is almost exactly the same (except I was going to write to different filename). Finally actually implemented this. Next up: qnet.dab
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/19ab720de38838ae2e4e1154
Modified Files:
src/sbbs3/main.cpp
Log Message:
Resolve recently introduced warnings about const char* to char* conversion

C++ <sigh>

We don't need a .ini section separator anyway.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/00a80d45d884c9ab547fef31
Modified Files:
src/sbbs3/main.cpp
Log Message:
exec/*.bin cmd shell filenames were case sensitive (must've been lowercase)

... while the mods/*.bin command shell filenames could be any-case!

Only impacted non-Windows systems (UNIX file systems are case-sensitive).

Discovered while making this tutorial video: https://youtu.be/HlwQ0uX4S04
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/76b5c7f4399c7774c368c754
Modified Files:
src/sbbs3/main.cpp
Log Message:
Resolve CID 492287 - we don't care about the fexistcase() return value here

We're just using it to "fix" the case, if the file indeed exists.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)