And a couple of projects didn't have the encode directory in their include path.

When no file description was provided (e.g. blind/batch file uploads), I noticed that the short file description (summary) could be set to "(null)". This problem was introduced in commit 4bd6f5f6 with the sbbsfile.des creation and post-processing support.

I also noticed that the extended description processing in sbbs_t::uploadfile() was not entirely consistent with other methods of adding/uploading files. Let prep_file_desc() do its just of processing the extended description into a suitable short description/summary (including truncation).

If the extended description is UTF-8, first convert it to CP437.

strip_cp437_graphics() is like strip_exascii(), except it'll leave the foreign language characters and math symbols intact (removing just the common "block" and "line-drawing" characters).

DEL (0x7F) is a control character too, so have strip_ctrl() remove it.

Apparently 4000 characters isn't enough for everyone to describe their files in vibrant colors and "graphics". :-)

This should address issue (feature request) #196.

The last 20 sets of displayed messages are stored as data/msgs/<user-num>.last.#.msg. This number is currently hard-coded, but could be configurable in the future. I say "sets" because messages are batched-up and displayed together normally, unless a user is actively polling for new users (e.g. while at the Ctrl-P/PrivateMsg prompt).

This involved getting rid of some copy/pasta in sbbs_t:getsmsg() as well by creating/using/reusing readsmsg().

- setInterval() returns a Number, not an Object.
- typos fixed
- markup added

The QWKnet user look-up feature was broken as of commit e4fc5d04 (a year ago).

Just noticed this regression as Andre asked in IRC about looking up network users for netmail. This feature worked for QWKnet users/addresses, at least, and now will work again.

This field should not normally have a value of '1' (no way to configure that, normally, since days are numbered starting at 1 and bit 1 is 2), but if it does, it's treated the same as 0 (any day of the month) - so fix that mismatch in getnexteventtime(). Just noticed this while comparing the logic with the new is_time_to_run() functions in main.cpp. That logic wasn't (should not have) changed, so this mismatch in the treatment of mdays == 1 existed before.

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

With this option set to "No", sysops can still login, they just can't perform most sysop functions.

Updated System Password help text to clarify that the "Allow Sysop Access" option effectively disables the system password. Also mention the FTP Server use of the system password to enable sysop access.

As Andre pointed out while documenting this setting on the wiki, the option seemed confusing: if a sysop could not login with "system operator access", how could they login at all? Answer: they could not.

This setting used to be called "Allow Remote Sysop Logins", back when there was the concept of a "local login", so setting this option to "No" would mean that user accounts with sysop access could only be used for *local* login. But in Synchronet v3, there's really no such concept as a "local login", so it was changed to just "Allow Sysop Logins" (period) and not a lot of thought given to how/why a sysop would actually set to this "No" or what the implications would be (presumably, nobody ever sets this to "No").

So rather than just get rid if the option altogether, I changed it to mean: an account with sysop access (i.e. level 90+) can still login, but any action that normally requires the system password will not be allowed. This includes the sysop-actions available in the FTP server when authenticating with <user-pass>:<system-pass> as the password. The sysop-user can still authenticate (and login), but none of those sysop-actions will be available to them.

Thanks to Andre for pointing that out in his wiki updates.

Convenient way to get the path/name of the archive file as it was passed to the constructor.

it just seems it's even worst than Deuce thought. :-)

This will allow naming consistency in encode/*
This is the fix you're looking for Keyop. :)

I noticed that the recent NASA "Earth Science Picture of the Day" files have had a DIZ with UTF-8 encoded apostrophe in it. <sigh>

Then you must also include the file extension on all the configured command-lines.

The opposite is not true: excluding the file extension in the native program list will still work if the command-line includes the file extension.

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.

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

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

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.