JS doors with the "Use Shell or New Context" option enabled in SCFG and JS
modules installed a global hot key handlers would not automatically terminate
when the user disconnected (and js.auto_terminate was true, the default).
I'm not sure why the operation callback was only installed when scope==NULL
but always installing it fixes the issue with some global hot key modules
and JS doors becoming "zombies" when a user disconnects while running them.

Fixes issue #390

Fixes isue #388 - no change in behavior

This converts the body text as well as the to, from, and subject header
fields (first to CP437, then to ASCII).

This should address the issue raised in issue #386 with exporting UTF-8
sequences to some message networks.

When loadfiles() calls sortfiles(), only the file's index records have been
read in, so trying to sort on any header field won't work.

This bug wasn't observable when sorting by date ascending, since that's the
natural index order of the files already (order imported/added), only
observed when sorting by date descending (newest at the top).

to accommodate larger numbers/strings.

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

(I'm looking at you, mist1221.zip)

... so first try to extract DIZ files from the root of the archive, then try again searching nested directories too. <sigh>

iniFileOpen() does not perform retries and there can be contention for the ctrl/dsts.ini file.

This was a regression (to just LF-terminated lines), an accidental change (from "text" to "binary" file-open) in commit 3bcab8a6.

Fixes recently-introduced crash when generating text drop files (e.g. XTRN.DAT, SFDOORS.DAT, DOOR.SYS, CHAIN.TXT) on Win32 (only) where a 'long int' is still just 32-bit.

Might add some other statistic for these relayed posts at some point.

Hunting down and destroying some super old SBBS code now. :-)

Defines the field indexes for records in csts.ini

Generates a "Dd Hh Mm" string from a specified number of minutes.

*/dsts.dab was replaced by dsts.ini.
*/dsts.ini is just a text file, you don't need a special editor.

*/dsts.dab (daily statistics and running totals) -> */dsts.ini
*/csts.dab (cumulative statistics / log) -> */csts.tab

* dsts.ini now has both daily and total stats for all fields (not just timeon and logons).
* dsts.ini is now an easily modifiable text file - no longer need dstsedit (here-by deprecated and soon to be deleted)
* dsts.ini and csts.tab support 64-bit upload/download byte stats and are very extensible for future fields to be added or extended > 32-bit (this was the main inspiration for this overhaul, but it was overdue and already designed for v4, pretty much)
* csts.tab is a tab-delimited fixed length record format suitable for easy import to a spreadsheet program or parsing with scripts. Each day is a 128-character LF-delimited record with tab-delimited fields of plain ASCII text.
* All fields except timeon in dsts.ini files are updated immediately and by more non-terminal servers (e.g. post statistics from web UI scripts).
* New user stats are tracked more than just for "today".

The upgrade of these files is automatic and built-into SBBS.

Still to do: overhaul the slog utility to support the new csts.tab file format.

Fix the fix to issue #380.

Thanks for letting me know Keyop.

And data/dirs/*.msg display file. Now you can have any supported menu file in this location if you wish.

I'm so tired of this 30 year old frequently asked question.

If a sysop really wants their Synchronet BBS to only work correctly for ANSI users, I suppose that should be their prerogative.

I always felt that by not detecting/displaying menu files when the minimum set of files was not present, I was helping sysops to identify an issue with their system (which would not work correctly for non-ANSI users). *And* I always felt that having a single menu/display file that correctly supported both ANSI and non-ANSI users was a nice convenience (who really wants to maintain multiple versions of their menu files?). But I'm so tired of answering this question, I just give up.

Hopefully this doesn't break anything for anyone. <shrug>

That previous commit made all *.40col.msg files display for 80 column users. Not my intention.

So revert to the previous behavior of *.XXcol.* display files. I didn't want to go renaming a bunch of menu files as a result of the previous commit and I didn't want a bunch of sysops with *.XXcol.* files to be suddenly surprised at their new BBS behavior.

And introduce a new file naming convention, *.cXX.* (where XX is a MINIMUM column width). This is the same naming convention used by Mystic, which also treats it is as a minimum terminal width, not a required exact width.

e.g. display basename.132col.msg even if the terminal is 133+ columns wide.

Fixes issue #380.

Fix for one of the problems described in issue #380.

bbs.menu("random*"); would display column-width-specific files (e.g.
random.132col.msg) even when they weren't appropriate for the current
user terminal width.

This is fixed by truncating the filenames matching the requested pattern at
their first-dot rather than the last.

The downside is, you can't have a set of random.#.* files, where # is the
unique part of the filename and * is the file-type extension. Just use
the naming pattern "random-#.*" instead (or something similar) instead.

Fixes recently broken Win32 build

I knew I created these is_valid_*num() functions for a reason!