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!

Fixes issue #327.

Also remove some old obsolete comments.

Increment the REVISION value manually (no more CVS keywords).

Hitting [Enter] is supposed to select the current/default program
section. Instead, it was quitting. This was apparently broken as
part of the xtrn_sec.js refactor a year or so ago by/with mlong.

If the child process (e.g. door game) has terminated, don't log errors if/when WriteFile() to the mailslot fails. This would be expected as the mailslot is created/owen-by sbbsexec.dll which would also terminate along with the process, thus closing the mailslot. 

Hopefully resolves the errors reported by DesotoFireflite (VALHALLA).

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

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.

As reported by Nelgin

Fix warning while we're here.

The value of the macro is INT_MIN, not zero to protect agains weird
edge cases.

I considered INT_MAX, but figured you could get there in sane ways.

The file_list[] parameter was expected to contain only files, but the directory() function (used to create that file_list[]) returns a list of all directory entries, including sub-directories. I could (and maybe will) add an option to directory() to only include files or dirs, but this seemed the more direct fix for the problem reported by DesotoFireflite (VALHALLA):

TickIT's nodelist_handler.js appears to be creating and leaving behind a sub-directory of the temp directory, triggering this error:
 1/23  11:36:56a  QNET libarchive error -1 (13 opening c:\SBBS\temp\event\nodelist_handler/) creating c:\SBBS\data\VERT.REP 

Why isn't the temp directory fully cleaned up after/between events? That's another thing to look into.

To address CID 345626

We need to re-parse the default sexpots.ini [TCP] section for every new session (when using the Prompt feature) or else there's no way to connect to the default host.

Also, telnet to be enabled or disabled (e.g. by setting Telnet=false) in any [TCP] or [TCP:x] section to support a mix of Telnet and non-Telnet hosts.

Also log a warning if a control character is received in response to the prompt, or log a notice if there's a timeout waiting for a response to the prompt. Change the non-control character response value to a debug-level log message.

Set CLS=true in the root section of sexpots.ini to enable. Sends a ^L ASCII 12 0x0c FF CS whatever you want to call it to the remote terminal before sending the carriage return and copyright banner. For Nelgin.

Set to number of seconds to timeout, if desired.
Log the received character in response to the prompt.

Wait up to 10 seconds for a single-char reply to the prompt and if a non-control character was received, use the [TCP:x] (x is the character sent by the user) from the sexpots.ini for the Host and Port values to connect to.

An experimental feature for Nelgin.

When printing a PETSCII Sequence (.seq) file, count the lines/rows and columns similar to how we would if we were using outchar() (but we don't, we use the lower-level outcom() to bypass any translations).

This is related to issue #325:
PETSCII seq files seem to display just fine, the problem I saw was with the auto-pausing (e.g. before a screen-clear) after displaying them.

Oh, QWKnet nodes ('Q' restricted accounts) are impacted by this restriction
since the poster's name isn't taken from the user account anyway.

So some cute user (mine@demon.com) created a new user account on Vertrauen with the alias and real name of "Rob Swindell". Funny.

Now, duplicate user aliases are already and always forbidden (even those that just vaguely match an existing alias) - everyone expects those to be unique. And we already forbid new user real names to match an existing user alias (check_name() enforces this and we use that when checking new user real names too), however, nothing prevented a new user account's alias from matching another existing user's real name. And this is a problem:

1. This new/fake user could post a message or send an email/netmail and it would appear to possibly come from the other/original user (we do have options to send mail and post messages using real names)

2. Received email for real names is supported and if enabled, this second account could be used to intercept mail for the original/first account if it was receiving mail for the original/real user's real name.

So disallowing a new user's real name to match an existing alias fixes one problem. 
However, systems *can* be configured to allow duplicate real names (which is convenient for QWKnet accounts, for example) and so we needed another solution for that problem: meet the 'O' restriction. This restriction flag will prevent a user account from posting messages no sub-boards that require real names. New user accounts that have a duplicate real name (the same as another user account's real name), will automatically be assigned the 'O' restriction flag. Systems that don't allow duplicate real names wouldn't have this issue in the first place.

Scripts that allow the creation of new user accounts might need some updating to match this security logic.

Eliminate some redundant code. Use the userdat lib function provided for this purpose.

Posting restrictions are handled one QWK-message at a time (and have been for a long time). No actual change here.

The system.check_name() check *also* verifies that the username is not
already taken, so we must perform the matchuser() check first in order
to get the appropriate error message here when trying to use an alias
(username) that's already taken.

Fixed a couple sprintf() buffer overflow warnings/issues.

for Nelgin

Default the progress time interval to 500 milliseconds (twice a second).

Don't specify a count/call interval in the call-sites, since we really want to use time-based progress updates now only and the default probably will work fine everywhere.

To send less text over slow (e.g. 4800bps) modems. For Nelgin.

This makes the interval argument unnecessary I think.

system.illegal_filename() - check if contains illegal chars/sequences
system.safest_filename() - check if contains only safest chars
system.allowed_filename() - check if meets criteria from SCFG->File Options
system.check_filename() - check if legal and meets configured criteria and is not in file.can
bbs.check_filename() - ditto, except will display badfile.msg as appropriate

Now scripts can utilize the sysop-controlled filename criteria and security of the BBS.