chksmb needed this to perform filename checks (index against headers).

This served exactly no purpose (since the idxrec_t existed at the same
offset in both parts of the union). So this was just some weird artifact
from the new filebase development.

Increasing size of mode[] element by 2 bytes eliminated these GCC warnings
that seem like false-positives to me:

sbbs.h:194:48: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
  194 |                                 (ret)[JSSTSpos]=(char)JSSTSstrval[JSSTSpos]; \
      |                                 ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
js_file.c:225:25: note: in expansion of macro ‘JSSTRING_TO_STRBUF’
  225 |                         JSSTRING_TO_STRBUF(cx, str, p->mode, sizeof(p->mode), NULL);
      |                         ^~~~~~~~~~~~~~~~~~
js_file.c:42:17: note: at offset 5 into destination object ‘mode’ of size 5
   42 |         char    mode[5];
      |                 ^~~~

Similar use of JSSTRING_TO_STRBUF in other files (js_console.cpp, js_archive.c)
(with larger target buffers) does not trigger the same warnings.

Ctrl-A - Select All
Ctrl-F - Filter IP address
DEL - Close Socket

Also, use Begin/EndUpdate() calls to batch updates to the ListView in Timer
tick (no visible difference, but it's the right thing to do).

I don't know why C++Builder increased the TextHeight value of this form from
13 to 15, but doesn't seem to really matter (or at least, I couldn't tell).

I don't know why this was set so wide (10 pixels), but that did help to easily
see that it was being placed in the wrong spot in the form (between the tool
button bar and the top panel). But we don't need it to be that thick. 1 pixel
is still enough to be able to grab it with the mouse and resize the top/bottom
panels.

For who knows how long now, the horizontal splitter that allows the sysop
to control the size of the top 2 panels (server forms), was displayed above
the top panel, not between the top and bottom panel, thus making the panel
heights not controllable. Weird. Change the order of making the controls
visible to insure that the splitter is displayed below the top panel and
on top of the bottom panel.

Also (non-functional changes):
Remove redunant mutex from client_on() - makes no difference.
Use try/catch in client_on() to try to catch VCL exceptions - doesn't catch
the "invalid index" error popups that we see on occasion. <shrug>

... bug introduced in commit 29a35642.

strListMerge() doesn't realloc the strings in the list, so we don't want to
free the strings in this list here.

This is likely the cause of the crash Keyop eluded to in #synchronet.

Reported by Keyop (upon being auto-disconnected overnight):
!ERROR 9 (Bad file descriptor) in data_ovl.cpp line 47 (putmsgptrs) writing
"message pointers" access=0

Unfortunately, the way putmsgptrs() was written, we couldn't tell if this was
an open (data/user/*.subs file) issue or a writing issue.

So create putmsgptrs_fp() and use that from sbbs_t::putmsgptrs(), so we can
log a different error (with more accurate details) if it's a file-open failure
versues a file-write failure.

The "from_ip" header field of QWK messages is checked against blocked IP
addresses, but was only checking against IP addresses from ip.can, not any
addresses listed in ip-silent.can. These 2 list files are now merged together
for the purposes of filtering during QWK/REP packet import.

Add '-v' (increase verbosity) option, used to display msg dates and timezones
... when using the the 'l' (list messages) command (to view post date/time).
Use '-vv' or '-v -v' to see timezones of messages.

The -v option is now also applicable to the 'v' (view) messages command (now
redundant with the 'V' command).

Features as requested by Nelgin as part of issue #786.

Removed day-of-week from date/times displayed. We don't need that level of
user-friendliness with this tool.
However, we are also displaying 12h/am/pm times. Some sysops probably would
prefer 24hour time, so that should be considered at some point.

... related to issue #786.

Also, don't check for a message-ID if the message-type does not match the
expected message type ("type mismatch").

1. When a 0-length bundle file was encountered or an unpacking error occurred,
   any remaining bundles for the current search day-of-week (e.g. *.SU*) would
   be skipped/ignored. This bug (issue #764, regarding the 0-length file part),
   is fixed by not incrementing the day-of-week index in the main loop, but
   rather only incremeting the index when all bundles for the current
   day-of-week have been processed.
2. The age calculation for 0-byte/length bundle files was incorrect, so all
   0-length  bundle files would always be considered "less than 24-hours old"
   (and thus, never auto-deleted).
   This exacerbated the problem of issue #764 since it would persist until the
   0-length files were manually deleted. Fixed the file age calculation and
   now logging the date/timestamp of the 0-length file as well.
3. Don't do the switch/case/sprintf dance when we're not re-running a glob()
   search.
4. Replace the switch/case statement with an array of week day names/patterns.
5. Ignore (with a warning log message) any sub-directories of the inbound
   directory that happen to match the bundle file search pattern.
6. Use better variable naming.
7. Refer to files with a length of 0 as "0-length" instead of "0-byte" in log
   messages.

I think this might fix issue #781. I suspect that SBBS (the MQTT client) is
being disconnected by the server ("due to protocol error") *after* the
call to mosquitto_connect_bind() is successful. We don't have any correponding
log output for this case, but at least we can track the connection status
accurately using the Mosquitto client callbacks and not try to publish when
we're not connected.

For cases where an mqtt struct is shared between threads without concurrency
control. I'm making this improvement in light of research into issue #781,
though I don't expect this change to fix the reported issue.

The reported error seems to come from the event thread (publishing node
status upon starting to run the "DAILY" event) when a broker connection was
not successful, however the reporter (Nelgin) may not have had debug-level
logging turned on, so didn't capture the successful broker-connect log
message. I think the broker connection *was* successful and perhaps then
terminated by the broker ("due to protocol error"?).

It appears I had the idea to make the CantPost text.dat string a format string
before, but never quite finished that change (e.g. made the change to
email.cpp and text.dat too).

There's a whole lotta calls to sprintf() then logline() that could be reduced
with this function.

For regular user QWK Relpy packet uploads only, if no timezone is specified
(e.g. via @TZ kludge or HEADERS.DAT), then over-ride the message's "posted"
date/time with the current date/time since we're going to set the message's
timezone to the BBS's local timezone as well.

This is a fix for issue #783 reported by Chris Jacobs.

If/when we support user-specified timezones, then this likely would be a
place where we'd want to use the user's timezone.

From todo list on Vertrauen, not in GitLab (shrug)

When no files with extensions are found, though they matched the glob()
pattern, a NULL pointer deref would result (segfault).

This could happen if the only files matching the pattern had no extenions or
were directories (not files).

Fix for issue #779

... this was the cause of some observed unnecessarily high disk/file server
(Samba) utilization, as we call getnodedat() a lot. utime() opens and closes
the file, which was already open - and we're not modifying the file, so
updating the 'modification time' here is wrong anyway.

Disabling this 21-year old bit of logic resulted in a pretty dramatic
reduction in Samba (smbd) CPU utilization on Vertrauen.

If a BBS actually needes this hack (e.g. for NFS compatibility, as Deuce
eluded in the comment), they'd be better off just setting the "Keep Node File
Open" node setting (in SCFG->Nodes) to "No".

I'v been getting errors locking user.tab (for read) for a while (over samba),
so hopefully this helps. The lockuserdat() total timeout duration extends from
about 5 seconds to about 45 seconds (with an incremental back-off).

Implement the same lock-retry logic/limit in putuserdat().

At least 512 bytes per call.

Eliminates GCC warning about not checking return value of write/sendsocket()

The expansion of LF to CRLF (with TG_EXPANDLF) is on receive.

For Nelgin

I'm not clear why Coverity suddenly thinks that getstr() doesn't
nul-terminate strings, but whatever: NUL-terminate the buf before passing it
to getstr(). <shrug>

HANDLE_PENDING() macro returns from the calling function (without freeing
allocated resources), so don't use that here.

Only the last node number specified would be listed before this fix.

No longer claim that 'list' is the default action (it's not).

If you want to list nodes, you need to specify the 'list' action.

Fix for issue #772

If an array argument is passed to these methods, the stringified contents of
each array element value will be sent to the remote server after connecting.

This is to support Nelgin's request of sending some strings to a server after
connecting. There's no way to insert pauses between the sent strings or wait
for certain output from the remote - that's beyond this scope/capability.

... since these methods only feed the keyboard buffer.

Add an optional 'insert' argument to console.ungetkeys() - default is false
(append).

Add a new version of console.ungetstr() which feeds the passed characters
directly to the receive input buffer. Now returns bool indicating success.
Existing scripts (if any) that use console.ungetstr() should continue to work
just fine.

This is anticipation of telgate.js being able to stuff strings (e.g. username,
password) into the input buffer and those chars/keys being passed to the
remote (gatewayed) telnet server. Since the telnet gateway reads directly from
the receive input buffer (ignoring the keyboard buffer), we needed a way to
stuff strings of characters into the receive input buffer directly and that
sort of exposed the weirdness of the existing console.ungetstr() method:
- it didn't return a return value (not indication of failure)
- it didn't support an 'insert' operation (even though the underlying C++
  method does)
- it didn't use the sbbs_t method that already existed for feedding a string
  of characters into the input/keyboard buffer

Calling exit() causes JS_ExecuteScript() to return false (same return value
as if there's a syntax error) - so if we always set exit_code in exit()
(even when not passed a parameter) and then use that exit code if the property
is defined, then we get the -1 return value from js_execfile() if the script
is terminated prematurely without using exit().

This fixes the issue introduced in the previous commit where scripts that
call exit() - without any parameters, were causing errors to be logged about
scripts (e.g. timed events) returning -1.

js_execfile() now returns -1 when JS_ExecuteScript() return false (failure).

The main command-shell loop will now terminate when js_execfile() returns
anything but 0 (success), similar to how PCMS (Baja-compiled) command-shell
.bin file parse errors are handled.

This is a fix for issue #340

Another idea would be to store a history of mail save paths and allow the user
to scroll through them/choose with the up and down arrow keys, but that goes
beyond the original feature request. So this just stores/reuses the last
successfully used path/filename.

... as appears to have been the intent

And really, more importantly, the msg header field_list array length would
always be interpretted as 0-length!

... introduced in commit 54523145

... introduced in commit 54523145

Include -pause and -loop options in usage help output.

Don't delay (sleep) one second when looping and -pause option is used.

Flush the output before waiting for key-press (-pause option is used).

This should all address issue #365. Sorry for the long wait.

When a user has a "default download protocol" selected (configured for their
user account), don't display a menu of file transfer protocols when we're
just going to auto-select their default anyway (e.g. when downloading a QWK
packet).

This change also introduces an argument (%s, the protocol name) in the
StartXferNow text.dat string, so that if/when the user forgets which default
download transfer protocol they had selected, they'll be reminded ("oh yeah,
I need start an XMODEM download!").

This fixes issue #767