1) Initialize saverobot.name since this is checked unconditionally.
   This has a side effect of initializing everything else, but name
   is the only thing that actually matters.
2) Add a bar to the global settings menu.
   Previously, if you scrolled near the bottom and selected an option,
   after changing the option, you would jump up to the last item on
   the initial screen.
3) Fix the AreaMgr Support default value to be the current, not the
   opposite of current.
4) Use the correct variable for EchoMail Relay Filtered Messages
   setting default.

We're carefully counting the errors, but never looking at the count.

Upon any node.dab lock or read failure, this code would cause errormsg() which
would often/usually end up claling getnodedat() which would block forever trying
to acquire the ndoefile_mutex (introduced in commit b9633069, I'm not clear why).

Unlock/release the mutex *before* calling errormsg().

Don't deref that null pointer

I dislike this particular code a little less now:
- no more redundant string compares
- less deeply nested if() and for() blocks
- remove added areas from the add list, rather than zeroing out the tag
- a little more common code between areas.bbs and areas.ini handling

No functional change (I hope).

"AreaFix" is a proper product name. Though it's been defunct and unsupported
for decades, we still should not confuse sysops and historians: the general
term for what AreaFix did/does is Area Management, aka Conference Management.

The sbbsecho.ini key names are unchanged and the destination netmail address
for AreaManager requests can still be "AreaFix" (though "SBBSecho" is still
supported as well).

and vice versa - so area manager requests were broken since I introduced the
areas.ini support. Oops.

I noticed through code review that these kinds of messages would be rejected
as "No commands to process.". We just needed to increment the 'cmd' counter
when parsing these options to be sure we don't think that no commands were
in fact request. -R (rescan) is not by itself a command since it requires
listed area-tags to have any effect.

... like how we do for areas.bbs files.

I'm not clear if/why these would cause the issue reporetd by
Fernando but they're definitely bugs in the areas.ini areafix
code. No impact to the areas.bbs areafix handling.

... in area manager code modified in previous commit.

It's possible the client requested binary transmit in only one of the two
directions and if so, restore just the direction that was previously *not*
in binary transmit mode to NVT mode.

This allows us to save unitialized telnet_*_option values (i.e. 0x00) and pass
those values back to request_telnet_opt() with no side effect.

Before this change, we'd always request a return to Telnet NVT (turn off
binary-TX in both directions) after any file transfer. So although a Telnet
session might be negotiated into binary mode shortly after connection
(e.g., using "telnet -8"), it would be reverted back to NVT mode after any
file transfer.

The request to turn off remote binary-TX after executing external programs
didn't actually accomplish anything since we track the Telnet option states
internally and don't send redundant requests (e.g. the change into a mode
we're already in). External programs aren't expected to send Telnet requests
anyway, so I think this was some holdover from early days of stp/sexyz
development.

Where's the compiler warnings guys?

As suggested/requested by Fernando Toledo in issue #826, you can:
1. run 'jsexec make_areas_ini.js' to export your areas.bbs file to areas.ini
   (your old areas.bbs is left in place, in tact, unmodified)
2. change your Area File in echocfg->Paths and Filenames->Area File to
   somepath/somefile.ini (e.g. "../data/areas.ini") and SBBSecho will use
   the .ini file format instead of the old AREAS.BBS format (NIH)

You can always go back to your areas.bbs file by just reverting the Area File
setting back to some other non-ini filename (e.g. "../data/areas.bbs").

Incremented version number to v3.23

Of course documentation and echocfg changes will need to follow, but this is
enough to start testing (looking at your Fernando! :-).

I tried to minimize the diff as much as possible and resisted updating
(modernizing, fixing) the very old AREAS.BBS parsing and areafix code.
The new .ini code is largely modeled after the old areas.bbs code, but oh,
xpdev/ini_file makes things so much nicer and easier.

There are no known fixes for any pre-existing area file/fix issues (including
issue #826), but it's always possible I've introduced a new issue.

Can't used designated initializers in fmutex_init() because this file is still
built with C++Builder6.

and might return before setting it to anything else.

For some reason, MSVC was initializing the time_t (second element of the
struct) to -1, not the int fd (the first element), which was initialized to
0. Weird.

The auto-remove param was only needed for fmutex(), which immediately closes
(and thus don't want auto-removal), so create an internal function that's
used by both fmutex() and fmutex_open().

This is needed for *nix where normal (i.e. not Samba-mount) file behavior
requires that we manually unlink() the file, but not until just before closing
it. So we have to keep track of the file name and the 'auto_remove' desire of
the caller. This is not necessary when the file is on a Linux-smbfs, but we
need to work as expected on normal/local *nix file systems too.

This solves atomic lock file removal for *nix, but does not gaurantee lock file
cleanup upon ungraceful process termination (e.g. crash). At least in this
particular case, Windows beats UNIX.

This reverts commit e55183c0.

fmutex_open()'s auto-remove feature doesn't work on normal/local Linux file
systems: unlink() of a file immediately removes its directory entry allowing
subsequent opens of the same file name, defeating the lock.

I had tested fmutex_open() on a Samba mount (from Linux) and it worked as I
wanted (like the Windows version does). Still searching for a good solution:
if a process terminates, gracefully or not, I'd like the file to be removed
at that time and until then, other processes or threads can't create or open
the same lock file (using O_EXCL and file locking to insure this).

Oh, so much copy/paste eliminated!

This condition caused aborting BBS operations via Ctrl-C to fail when
connecting from a traditional Telnet client using binary transmission
mode (e.g. telnet -8) or SyncTERM v1.2rc6.

The check of rio_abortable was probably enough to disable this function
during file transfers (e.g. we've had no issues with SSH file transfers
that might include byte 0x03 received from the client), but I added the
check for SS_FILEXFER system status check too, perhaps unnecessary.

On *nix, you need the command shell to do wildcard expansion of filenames

Add the errno value to help root-cause.

We really should be using safe_strerror() everywhere.

This appears to be the only way to 100% provide mutual exclusivity between
Windows and Linux client sharing a Samba file system.

Also, make fmutex_close() take a pointer to the file descriptor so that we can
better manage the resource (i.e. don't close a descriptor that's already been
closed and possibly valid in another thread).

... which simplifies the fmutex_close() function and signature.

By default, the duration is infinite, but some sysops may not want this
file to be ever-grower but rather periodically pruned by the new trashman
utility.

Sysop that don't use spambait.cfg won't benefit from this change.