This fixes the issue reported by Nelgin with the [mail] RescanFrequency new
default value of "1h" being interpretted as one second intead of one hour.

working reliably though.

With this change, it's important you don't try to use a newer text.dat with an
older sbbs (and perform a ;UPLOAD sysop operation).

Previously, each file's size in (k)ibibytes was displayed, which is not very
modern of us. Use the byte estimate (e.g. "1.2M") strings intead.

We were appending .sig files to uploaded text, which may not have ended
in an LF or CRLF sequence. This fixes that.

No one's using this function currently (and may never).

It was used back when I was putting archive contents in .ini format in the
files' metadata (now auxdata).

Currently disabled, but library is built and linked.
Initial usage will be to write public key to remote... interestingly,
I think Synchronet may currently disconnect users if they attempt to
create an sftp channel, so that'll require some kind of magic to ensure
SyncTERM still works on current version of Synchronet, but still
try to auto-update on future ones.

Various bits were wrong... now less wrong.

To eliminate confusion with the file-meta-object that this API deals with
more than anything else.

echicken's suggestion

Nothing used this property before now, so this should be fine.

... only operates on a single directory currently. But this should be enough
of a proof of concept for echicken to work with for now.

Ideally, this would be a feature of addfiles.js and file-uploading via the
terminal server and FTP servers.

Because we can. :-)

64 is not ASCII C, and it does not respond as @Term.

Don't allow smb_removefile() to corrupt a filebase if passed an uninitialized
(not fully load()'d) file_t*. Doesn't fix a bug, just some extra defensive
programming here.

Addressing problems reported by echicken

echicken reported this problem: pretty severe filebase corruption as a result
of calling FileBase.renew(). The problem seemed pretty obvious (only loading
the file's index record), but I do think the underlying SMBLIB functions
should be more resilient to misuse and not corrupt the base. So, that's still
a TODO.

No existing scripts were using FileBase.renew(), so this problem has gone
unnoticed since SBBS v3.19.

A couple of failure conditions from this function (e.g. SMB_ERR_HDR_LEN)
would not write an error descripton to smb->last_error. Now fixed.

Noticed this when debugging echicken's reported FileBase.renew() issue.

which were result of QWK_NEWLINE redef to make cppcheck happy

How I accomplished this (since I tend for forget):

1. Copy the 3rdp/src/cl from a current *nix build to a system w/MSVC2022
2. Remove the I/O/eap*.c files from the project (don't exist, not needed)
3. Change the build configuration to Win32 Release
4. Resolve misc\int_api.c(700,16): error C2099: initializer is not a constant

   misc\int_api.c int_api.c
   697a698,700
   > #undef CURRENT_TIME_VALUE
   > #define CURRENT_TIME_VALUE 0x6588BADC

I guess this version of MSVC isn't "tough enough",  though apparently MSVC2017
was.

This should fix CI builds.

This one is hand-crafted for CP437.  Ideally, I'd find the actual
Apple ROM fonts and compile those in.

SSH channels, I noticed that I hand't ever finished the terminal
type/size "stuff", and while fixing that, I noticed that the hack
for SyncTERM was done wrong.

Fix the whole thing, and now Synchronet and SyncTERM both properly
support terminal type and size over SSH.  It also looks trivial to
support the SSH window size change message, but I'm not doing that
tonight.

Unfortunately, this is a patch on a patch, so is a bit fragile.
It should really have the patches merged at some point.

netmail.cpp:411:25: error: Invalid strchr() argument nr 2. The value is -29
  but the valid values are '0:255'. [invalidFunctionArg]
  char* tp = strchr(to, QWK_NEWLINE);  /* chop off at first CR */

Just a proof-of-concept for right now, there's a couple major changes
and some minor changes that will need to be made before this can
actually be enabled.

Not really testable without some seriously terrible hacks right now,
but it has been verified with the sftp client that ships with openssh
(which is based on a 20-year-old internet draft that is both expired
and superceded).

This was not a real leak, but still, good practice

error: Uninitialized struct member: node.misc [uninitStructMember]

[integerOverflow]