https://gitlab.synchro.net/main/sbbs/-/commit/3f17c245f7a2e514826e9a26
Modified Files:
src/sbbs3/logon.cpp
Log Message:
Don't modify useron.misc during logon, even for AUTOTERM

We shouldn't need to set any of the autoterm flags in useron.misc these days (term_supports() checks autoterm when appropriate).

Try this Nelgin.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/88cef39afc51baf131c5a41f
Modified Files:
src/sbbs3/logon.cpp
Log Message:
Beautification of the previous commit

And don't store the autoterm flags in useron.misc even when correcting a manual-PETSCII configuration.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/f5fed0b229e70b79a5ebb330
Modified Files:
src/sbbs3/logon.cpp
Log Message:
Fix access-control by terminal cap issue introduced a week ago

In commit 3f17c245, I was addressing the issue reported by Nelgin via IRC: <nelgin> If you login using a term that doesn't support ansi, it changes your settings - can you set 'em back when done?
<DigitalMan> if you have auto-term enabled, it doesn't actually change your settings, just what's in use during that session
<nelgin> I logged in using my BBC emulator which doesn't do ansi, then when I logged in through syncterm, I got the display like it was on the BBC. All my characters replaced with #'s and stuff.
<nelgin> I had to go back into the user menu to fix it. That is going to confuse users.

However, the chk_ar() function in userdat.c which is used to populate JS objects (e.g. xtrn_area.sec_list[].prog_list[]) uses the user.misc value (cannot call term_supports()), so the current user terminal flags need to be reflected in user.misc always. So the real fix for the originally reported problem is to clear the charset-related terminal settings when logging in with auto-terminal settings enabled (and before the auto-detected charset flags are OR'd in).

I toyed with the idea of storing a copy of the term_supports() result in client_t, which is passed to chk_ar() when appropriate, but decided that was a bit overkill and there were issues with servers that don't have term_supports (e.g. the web server) and properly populating access-controlled areas in the JS object model (e.g. door games that require ANSI). Better to use the last-auto-detected terminal caps than assuming "no" terminal capabilities in that scenario.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/c0ef762adf57ff91307c3015
Modified Files:
src/sbbs3/logon.cpp
Log Message:
Remove defunct files from batch download queue during logon

If a user doesn't have access to download a file that's in their batch queue, remove it without saying anything to the user (but log a notice-level message about it) during logon. Files that no longer exist in the filebase are treated the same way.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/8266da9c329d2ba49ff2001c
Modified Files:
src/sbbs3/logon.cpp
Log Message:
Log an error if getstats() returns a failure

I saw my logon.jsonl file getting cycled multiple times a day recently on Vert and suspect this function call may have been failing.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/e12c35049251dc97e8eafd7c
Modified Files:
src/sbbs3/logon.cpp
Log Message:
Revert "Log an error if getstats() returns a failure"

This reverts commit 8266da9c329d2ba49ff2001cf542a0d05dc9987e.

We're already passing a sock_init callback (ls_cb) which is supposed to set
the socket options (call set_socket_options), so this change shouldn't be necessary and reportedly caused more issues binding ircd sockets when running ircd.js via jsexec (though I didn't see this myself).

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/46f1f80e75b30d477cdb419c
Modified Files:
src/sbbs3/logon.cpp
Log Message:
Revert "Revert "Log an error if getstats() returns a failure""

This reverts commit e12c35049251dc97e8eafd7c7fc12dfd9ba13ad9.

Wrong commit reverted. Oops.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/65f1df280bc72439e80b8a9f
Modified Files:
src/sbbs3/logon.cpp
Log Message:
A todo comment

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/cbf6a8b24c615e753801dbd2
Modified Files:
src/sbbs3/logon.cpp
Log Message:
I'm not sure what "node message indices" (data/msgs/*.ixb files) are/were

I don't recall this actually being a thing, ever, so certainly no reason to
be cleaning these files up during logon. <shrug>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/f315f34ce2c8b91e656fc5a4
Modified Files:
src/sbbs3/logon.cpp
Log Message:
Change "On two nodes" to "On more than one node", since it's possible it's > 2

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/9544a3c6bf36555a2babc6bb
Modified Files:
src/sbbs3/logon.cpp
Log Message:
Don't send NodeLoggedOn message to any nodes if user isn't being logged-on

If user is being kicked off for being on "More than one node at a time", then don't send a message to other any other nodes that the user logged-on successfully (they haven't). Previosuly, it'd send messages to all the lower-numbered nodes that were in-use (but not by the same user).

Reported by Nelgin.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/c345c6ad034f1e64db2b88de
Modified Files:
src/sbbs3/logon.cpp
Log Message:
Clear the Guest user's language (lang) field during logon - revert to default

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/3bcf61744225d8898eae6a00
Modified Files:
src/sbbs3/logon.cpp
Log Message:
Always close csts.ini file, even in error path (failure to open dsts.ini)

Fix for CID 509720

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/69e23e724e4e9dd2cd905b7d
Modified Files:
src/sbbs3/logon.cpp
Log Message:
Move the backup of dsts.ini before opening the file

Can't backup (make copies of) an open file.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/3b602ca5349f2b4143ff27ab
Modified Files:
src/sbbs3/logon.cpp
Log Message:
Check return value of getnodedat()

Should fix CID 515599 since this seems to be the only place we call unlocknodedat() without possibly not owning the nodefile_mutex already.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/b6b3e89091f941ab6ba3ea01
Modified Files:
src/sbbs3/logon.cpp
Log Message:
Actually use the (first) shell we found that the user meets the requirements

As discovered and reported by Deuce and Nelgin

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/437b1a13e91a9878480671d7
Modified Files:
src/sbbs3/logon.cpp
Log Message:
Don't backup dsts.ini daily

Looks like an unintentional debug-inclusion with commit 2064f3a4f71c6656693a1 as pointed about by Deuce in IRC.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/9eaeedc13950d1ec26af5963
Modified Files:
src/sbbs3/logon.cpp
Log Message:
Do rollover daily stats (dsts.ini) if the previous date was Jan-1-1970 (never)

Basically revert commit 2064f3a4f71c6656693a1d24fc63004c3c41aaea

In a new install, the "Date" value in dsts.ini will be 0/Never and thus would never be rolled over (e.g. stats moved o csts.tab files).

Since getstats() now reliably detects any read failures, we shouldn't need
this as a work-around any more anyway - if the "date" field is 0, it just
means a new install and it's expected.

This should fix the issue reported by Basis where the ctrl/csts.tab and node*/csts.tab files were never created in fresh install of v3.20. A work around is to just set the Date field in the ctrl/dsts.ini file to the current date (one time).

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/ae706b8054af1f291bfcd9ca
Modified Files:
src/sbbs3/logon.cpp
Log Message:
Don't turn off the "ASCII only" user setting during logon

... when auto-terminal-type detection is enabled for the user

Fix for issue #923

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/53c42100db8385eb3a965888
Modified Files:
src/sbbs3/logon.cpp
Log Message:
Better error reporting in logonstats()

Eastside75 (THUNDER) is reporting that their daily statistics (ctrl/dsts.ini) file is never "rolled-over" and there are only a couple of potential errors
in this function that could "silently fail" if the current date/time or the "Date" value in the dsts.ini file could not be converted to a broken-down date/time. So if either of those errors happen, log an error. It's unknown
what the cause of Eastside75's issue is, but I wanted to at least eliminate these 2 possible errors (failures in calls to localtime_r()) as potential causes.

Also, cleaned up a little using new dates_are_same() function, etc.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/a51dd4dc5d08d22fee21c3c0
Modified Files:
src/sbbs3/logon.cpp
Log Message:
A blank ReadYourMailNowQ text.dat string will not defeat the Unread mail prompt

I sbbs_t::noyes() will return true if this string is blank, so we didn't need check here now anyway.

Setting ReadYourMailNowQ in text.dat to an empty string means this prompt
won't be shown and the read messages will *not* be shown during logon.

Setting ReadYourUnreadMailNowQ in text.dat to an empty string means this
prompt won't be shown and any unread messages *will* be shown during logon (automatically).

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/377454c2db49f071cf24188c
Modified Files:
src/sbbs3/logon.cpp
Log Message:
When displaying unread mail during logon, use user-preferred sort order

Update to fix for feature request #1027

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/44a09ba9a32efbfef5497f80
Modified Files:
src/sbbs3/logon.cpp
Log Message:
Use check_realname() here when prompting for a user realname during logon

... because the user's real name is blank.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/80ac8be8e98a4e3cd1dcd36d
Modified Files:
src/sbbs3/logon.cpp
Log Message:
If user manually enabled ANSI term but logs-in with PETSCII, enbable autoterm

<@Deuce> DigitalMan, connecting to cvs.synchronet port 64 in C64 mode, I'm getting ANSI and CP437 after login.
<@Deuce> But it's properly PETSCII until then.

We supported the opposite scenario (manually enabled PETSCII), but not both
of them.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/aa0539b89b1d1d2ffb728843
Modified Files:
src/sbbs3/logon.cpp
Log Message:
What appears to be a more complete fix for auto vs manual terminal adjustment

... during logon.

Previously, we really only handled toggling between PETSCII and ANSI/CP437 but didn't really handle toggling between a UTF-8 and non-UTF-8 terminals. That's now handled here too.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/615f65ff9caef89548e79bcf
Modified Files:
src/sbbs3/logon.cpp
Log Message:
If the text/menu/logoninfo.msg file exists, display that during logon

In place of the system/logon information text strings (e.g. SiSysName, LiUserNumberName, etc.).

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/baf1e0dbca58a2b17b7b0cfd
Modified Files:
src/sbbs3/logon.cpp
Log Message:
Prompt for user's gender and birthdate if required by sysop, but invalid/blank

Copied pretty much verbatim from the old newuser.cpp logic that now resides
in newuser_prompts.js. So this should probably be replaced with a loadable module at some point (too).

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/887d6b2c07acbb98cc6449bf
Modified Files:
src/sbbs3/logon.cpp
Log Message:
No longer prompt for missing user fields/properties here

This logic is being moved to logon.js for greater sysop customization possibilities.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/bcd74f4f124ba2f12f1289dc
Modified Files:
src/sbbs3/logon.cpp
Log Message:
Fix race condition with concurrent instances updating stats files (?sts.*)

If you run multiple instances of sbbs sharing the same data files (I know you don't) *and* you have more than one instance running the terminal server timed events thread with "New day events" enabled (the default), you ran the risk
of more than one instance updating the various stats files at midnight and racing with each other, e.g. (nodes 11, 6, and 1 are all different instances
of sbbs):

events11:2026-01-07 00:00:01 BBS Events New Day - Prev: Tue Jan 06 2026 12:00 am
events11:2026-01-06 00:00:14 BBS Events New Day - Prev: Mon Jan 05 2026 12:00 am
events6.log:2026-01-07 00:00:08 BBS Events New Day - Prev: Tue Jan 06 2026 12:00 am
events.log:2026-01-06 23:59:59 BBS Events New Day - Prev: Wed Jan 07 2026 12:00 am

The "prev" date being in the future is an obvious check, but also double-checking the date in the dsts.ini files after we open each for update and log if the date is unexpectedly already set to today or the future.

This issue likely didn't effect anyone but Vertrauen, but I observed it when scrutinizing 'slog' and SBBSCTRL->BBS->View->Statistics Log output and
noticed a stuttering in the logged dates, e.g.

26/01/09 T: 166 L: 20 P: 4 E: 10 F: 22 U: 155M/4 D: 828M/1810 N:2 26/01/08 T: 114 L: 16 P: 6 E: 25 F: 12 U: 0M/0 D: 1G/9695 N:1 26/01/07 T: 64 L: 17 P: 0 E: 11 F: 4 U: 0M/1 D: 895M/2002 N:1 26/01/06 T: 0 L: 0 P: 0 E: 0 F: 0 U: 0M/0 D: 0M/0 N:0 26/01/05 T: 0 L: 0 P: 0 E: 0 F: 0 U: 0M/0 D: 0M/0 N:0 26/01/06 T: 55 L: 9 P: 2 E: 14 F: 7 U: 0M/0 D: 3G/6981 N:1 26/01/05 T: 519 L: 13 P: 4 E: 8 F: 4 U: 0M/0 D: 671M/2241 N:3 26/01/04 T: 234 L: 17 P: 7 E: 44 F: 2 U: 0M/0 D: 251M/1209 N:2 26/01/03 T: 120 L: 23 P: 5 E: 41 F: 8 U: 0M/0 D: 377M/3061 N:25 26/01/02 T: 189 L: 13 P: 5 E: 25 F: 8 U: 0M/0 D: 785M/5561 N:5 26/01/01 T: 81 L: 20 P: 6 E: 36 F: 16 U: 1M/1 D: 400M/3258 N:4

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net