Don't count read closed channels against "is this the last one?" checks
Fix checking of channel attributes are present.
Fully close readclose channel if it's the last one.

Previously, there were (basically) three states... active, closed,
and writeclosed where writeclosed indicated that a channel close
message was sent, no more writes are allowed, and it's waiting for
the close to be acked.

This adds a readclosed state where we have received a close request
from the remote (and acked it), but have not deactivated the channel
ourselves.

This fixes a race condition where we could select a channel, then,
when we write data to it, we receive a close and the channel becomes
inactive so a new active channel is selected (effectively at random).

This is a bit suboptimal though since we still don't get a
notification when a channel is closed by the remote.  Instead, if
we use more than one channel, we need to periodically make the
channel active for writes and explicitly check if it's closed.

If you initially try private key auth for example, allow retrying
with password auth and vice-versa.  This is needed for reasonable
fallback from private-key auth since we don't know in advance
which will work, and we don't want to disconnect an reconnect.

This takes the guardrails of adding a password.  Previously, it was
ensured that a password was always added immediately after a username.
This is to ensure when using the server for example and stuffing a
list full of all the user/pw pairs, each pw goes with a user.

Instead of returning an error, this now allows adding passwords
without a corrsponding user that won't be used, and there will be
no indication of why.

Death Star mode for this feature is better than not having fallback
in my opinion.

The Global Login Requirements (default: blank) are used for any sever that doesn't have it explicitly set.

This resolves issue #666 (the issue of the beast) for Keyop

(missed as part of previous commit)

e.g. User.downlaoded_file() will now publish to the appropriate MQTT topic and changes to system.node_list[] will get published to MQTT.

The old default Win32 console mode is still available via '-iw' option.

As pointed out by echicken: when setting the "cost" property to any value, the actual
file's cost would be set to 9223372036854776000 regardless of what number was in the
provided file metadata object. Most jsval numbers aren't doubles (they're ints) so
need to use JS_ValueToNumber() to do the proper conversion, regardless of underlying
type.

Noticed the same problem with the "size" property.

Thanks for the tests and report echicken!

DDMsgReader: New sysop features while reading a message: Show message hex dump (with the X key) and save message hex dump to file (with Ctrl-X)

See merge request !379

Eric Oulashin authored 1 year ago and Rob Swindell committed 1 year ago

DDMsgReader: New sysop features while reading a message: Show message hex dump (with the X key) and save message hex dump to file (with Ctrl-X)

that returns the SSH public key in the right format already.

This may be all SyncTERM needs unless it wants to add in a Midnight
Commander clone for browsing sftp servers.

In Windows 11, "Windows Terminal" is now the default console (though the
Windows user can change that to the old conhost.exe).  Running UIFC
apps (e.g. SCFG) in Windows console mode from within a Windows Terminal
console doesn't always display correctly (depending on the width of the
console). And even if if the app displays correctly at first in console
mode, it's very easy for the user to resize the console window and just
totally foobar the display of the app.

Windows console mode (previously, the default interface mode) is still
available ("-iw" option) if one wants to use it instead.

However, stdio/door mode ("-id") and ANSI mode ("-ia") can't be used directly
from a console.

The help/usage output is sent in Windows console mode (not stdout or GDI mode)
so it creates a new window, disables mouse support (so you can copy text from
it). stdout doesn't work from GUI apps. Fun times.

... to disable the OS or Window Manager's "close" app icon/control/option
which attempts an ungraceful termination of UIFC apps (e.g. SCFG) and does
weird and wonderful things (e.g. infinite loops which are invisible on
Win32-GDI, so you end up with a ghost/zombie process).

Disabling the OS/WM close option is an alternative solution to checking
uifc.exit_flags & UIFC_XF_QUIT everywhere you need to to avoid a
looping/zombie process.

Next up X11, which appears I need to remove _NET_WM_ACTION_CLOSE
from the _NET_WM_ALLOWED_ACTIONS Atom... ?

This reverts commit fddbd721.

Causes MSVC warning:
msgtoqwk.cpp(249): warning C4309: 'initializing': truncation of constant value

This reverts commit e90e8f82.

Apparently this causes issues with recognition of the QWK newline char
(pi symbol, EX-ASCII 227) in QWK messages.

comparison of integer expressions of different signedness: ‘int’ and ‘long unsigned int’ [-Wsign-compare]

syncterm\bbslist.c(778): error C2146: syntax error:
  missing ')' before identifier 'SCNx8

We aren't defining this standard format macro in gen_defs.h (maybe we should
be?) - but as long as MSVC has inttypes.h, seems we should be using that
instead.

This should fix the SyncTERM-MSVC build pipeline

The property name in cryptlib suggests it's a SHA1, but it's only
16 bytes long.

This should ensure that once quit is used, everything exits, but
apparently, this never worked.

C headers don't need C++ stuff.

We can now get the path to the users home directory on the remote
system.

This introduces the use of error fields in the sftpc_state struct,
which should allow result-or-error style stuff pretty easily.