Another hack for Nelgin: this'll allow (in theory) the serial device to switch parity modes (e.g. 8N1 or 7E1) depending on what the user selects (key pressed).

I did not add byte/stop bit size configurations. We may need that.

Set Parity=true in [com] section of sexpots.ini
Set ParityOdd=true if using Odd parity.

For Nelgin's null modem setup, putty doesn't raise DTR?

<nelgin> sexpots   1492                               root    3u      CHR               4,64        0t0         90 /dev/ttyS0
<nelgin> Well, it's listening, but when I connect with putty I get nothing.
<nelgin> DigitalMan, probably always assume a client is connected since I have my pc wired to my linux box.

Allow a configured maximum-severity (minimum value) for TLS-related log messages. Default is 0 (LOG_EMERG, maximum severity).

Getting tired of SMTP/TLS (SMTPS) related errors clogging up my inbox. I'm setting this to "Warning", like I did for [web].

Just in case a sysop deletes/changes their addresses after create subs, find the nearest matching configured system FTN address/AKA and use that.

DD file lister: Fix for left/right navigation for command bar introduced in last commit

See merge request !137

DD file lister version 2.01: Fixes for file description and command bar refreshing

See merge request !136

info.  Fixed command bar refreshing when pressing the hotkeys.

Created a file lister (in JS) that lists files in the user's current file directory

See merge request !135

directory with a lightbar interface, as well as message windows etc.

If the user does not have an ANSI terminal, this lister will run Synchronet's
stock file lister interface.

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

In commit 9a9c26f4, 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.

Users with the 'O' restriction (automatically set if a new user has the same "real name" as another account, and that's allowed by the sysop) will send netmail from their alias and not their real name to prevent impersonation of another user.

Don't let (or at least try to prevent) a sysop create a duplicate message group or file library internal code prefix (which could lead to duplicate internal codes for subs and dirs, pretty easily and accidentally).

When manually adding a message/file area or modifying an internal code value, reject the code if it's a duplicate.

This required that getsubnum() and getdirnum() support non-prepped configurations (where the full internal code has already been constructed from the prefix and suffix).

These 3 'stats' properties were read-only (never used when adding a file). To support moving files between FileBases while retaining these stats, support the parse/use of these file-meta-object property values.

Should fix issue #333 reported by Nightfox.

So Hobo and I have noticed that Global War was leaving game lock (*.LOK) files behind when he disconnected while in the game (e.g. due to the game not responding or something). 
This was happening because GWAR was not recognizing the loss of connection ("carrier detect" or DCD) and SBBS would ungracefully terminate the process after 5 seconds of being disconnected, thus the game lock files would remain and requiring manual clean-up.

I discovered that if I changed the WAR.CFG file to use FOSSIL instead of UART, Global War would then correctly recognize the loss of carrier and exit gracefully (and not leave any .LOK files behind). So... I suspected an issue with the Virtual UART driver. It turns out, that a program that relies on the modem status register change interrupt (and doesn't "poll" the UART MSR register) might never know that the "carrier" was lost. This is fixed by waiting on the hungup_event in the interrupt_thread and deasserting DCD in the "virtual" MSR register and asserting the MSR change interrupt to notify the program that it has in fact changed. Good thing for WaitForMultipleObjects(). Uh huh.

This one was one of the last TODO items for the new filebase implementation: It's been supported (for a *long* time) that a file tester/upload processor could change the uploaded file's name or description by modifying the contents of the sbbsfile.nam and sbbsfile.des files in the node's directory (I know, great names, eh?). These files were not read-back into sbbs to apply any changes in v3.19b and that's now "fixed" though I'm not sure any file upload tester/processor actually ever made use of this feature.

Also as part of this change, the '%s' specifier for the tester command-line will now be replaced with the path to the sbbsfile.des file and not the file's description itself (which could easily have been problematic for a command-line).

Updated SCFG help text to suit.

Testable File Types and Download Events support working strings (display before/while the command-line executes). Clear the current line (displaying this working string) when the execution completes.

Issue introduced in v3.19: Testable Files (a.k.a. upload processors) with a specified file extension/type (e.g. "ZIP" and not "*") would never run because the file extension comparison logic was "off by one". Testable Files with an extension of "*" (all files/types) would still run however.

This fixes issue #331 reported by Nightfox.

If the request is to a virtual web host, don't recognize the filebase vpath prefix (FileVPathPrefix setting) unless FileVPathForVHosts is set to "true" (in the [web] section of sbbs.ini).

This addresses another of Deuce's concerns about this feature.

Make it more accurate/clear:
"attempted to upload invalid path/filename"

The logged error "!attempted to upload to invalid directory" did log the actual path that was attempted to be uploaded.

Added some quotes around other logged paths.

Nelgin: "anyway to get sexpots to report itself differently to syslog" [?]

An int is 32-bits on all supported platforms, so this has always been broken. The actual file size/request-length sent would depend on fun 2's complement math (a 32GB file was being truncated to 433MB).

Also fixed some wrong uses of PRIuOFF: off_t is a signed integer, so technically the maximum file size you can request now is 2^63 bytes, which is "big enough".

Only used in manual answer mode,
RingCount defaults 1 (answer after the first ring) and RingInterval defaults to 6000 (maximum elapsed milliseconds between rings of the same "call").

This should address issue/feature-request #330 by Nelgin. Give that a try.

Another log message reported by  DesotoFireflite (VALHALLA) that can happen when a user has typed something while the programming is running and the program terminates before the data can be sent to it.

It bothered Deuce having a web server setting in scfg_t/SCFG->File Options, so I moved this setting to [web_]startup_t and the sbbs.ini file.

The downside is that file_area.web_file_prefix is no longer available to JS environments outside of the web server and terminal server, but meh, probably not going to use it elsewhere anyway? I can imagine use cases for JSexec scripts to want to generate URLs to filebase files. If that ends up being a need, they'll have to find and parse the "right" sbbs.ini file to determine the vpath prefix. 

This change is just for internal consistency and convenience right now: the lib_t.vdir is a "sanitized" copy of the lib's short name (spaces are converted to dots or underscores based on the logic that the FTP server used in dotname()) and the dir_t.vdir is just a pointer to the dir's code_suffix. No other permutations are made (e.g. lower-casing the strings). Although the virtual directory names of libraries will now appear in mixed case in the FTP server (previously, they were all lowercase), the directory names are actually treated case-insensitively, so it should not make any difference. If forced-lowercase is preferred for some reason, please speak up.

This change leads the way to eventually, possibly, making these virtual path elements sysop-configurable. For now, it's just better to have a *copy* of the lib's short name that is appropriately modified to make a suitable directory name and have that vpath element available globally (to all servers and services) in a consistent manner.

So Nelgin asked (about filebase access via http), what if the library short name has a space in it? The answer now is, the spaces are replaced with a '.' or '_' (if there's already dots in the name).

... more aligned with a sub-board's internal code help text.

This fixes issue #328.

The user actually *can* remove files from the batch queues in v3.19b, but you have to type the filenames which is not obvious from the prompt which implies you need to type the file index position (e.g. '1' for the first file in the queue). In all Synchronet versions prior, you could only remove by number (and not by name).

The fix is to allow either the number or the name of the file to be entered at the RemoveWhich prompt and the file is removed from the queue successfully.

Thanks Ragnarok!