This also addresses the addresses with 65535 in them in the new debug-level
log messages "New packet (type x) created for linked-node" .

Should fix issue reported by Floffy on IRC.

To complete the request from: Max (WESTLINE)

  Is it possible to do a new dateformat in scfg
  In sweden we using YYYY-MM-DD format as standard.

The default will be '/'.  Technically, any separator is possible by editing
the "date_sep" value in the global section of main.ini.  SCFG allows the
most popular separators: /.- and space.

... and YYYY/MM/DD for birthdate input/display.

Now set in SCFG->System (not toggle options) and stored in the "date_fmt" key
(new) in main.ini. The old sys_misc SM_EURODATE flag is deprecated (but used
to determine the default value of date_fmt when not present).

As requested from: Max (WESTLINE)

  Is it possible to do a new dateformat in scfg
  In sweden we using YYYY-MM-DD format as standard.

Merge branch 'dd_msg_reader_indexed_newscan_no_messages_dont_display_if_already_displayed_indexed_menu' into 'master'

DDMsgReader: With the indexed menu, don't show "No new messages" if the indexed menu has already been displayed

See merge request !381

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

DDMsgReader: With the indexed menu, don't show "No new messages" if the indexed menu has already been displayed

This completes the revert of commit c22063f9 from (Jun-2-2016). The Baja
part of that commit was reverted in commit 932fae30 (Nov-15-2016). This
behavior has proven to be surprising and annoying for JS mod developers
(e.g. the yesnobar.js and Nightfox's file searcher/scanner).

If we still need clearing of abort status after running JS "externals",
that should probably be done in exec_xtrn(), not here.

Should calm the clang warnings reported by Deuce:

e.g.
passing 'char *[18]' to parameter of type 'const char **' discards qualifiers in nested pointer types

CID 476253

The 4th enhancement request of issue #674

The other requests look a bit more involved than I'm willing to explore right
now. And Deuce reassigned this back to me. So that's probably all that's going
to be done.

When flushing, set timeouts high, then set zero read timeout
Ensure channel IDs are protected by the ssh mutex
Check channels are open every time though input thread and before sends
Fix various locking errors
Install public key in a background thread

Once a startup race is fixed, this should be good to go!

and before the first response.

DDMsgReader: For indexed mode newscan, default to showing "No new messages" instead of showing the indexed menu if there are no new messages. This can be toggled via a user setting & new configuration option, displayIndexedModeMenuIfNoNewMessages

See merge request !380

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

DDMsgReader: For indexed mode newscan, default to showing "No new messages" instead of showing the indexed menu if there are no new messages. This can be toggled via a user setting & new configuration option, displayIndexedModeMenuIfNoNewMessages

Go ahead and fix false-positive CID 33482 by adding a NULL check to quotestr()

CID 462234

Even though smb_getmsghdr() just saves and restores the msg.idx_offset value
(not actually using it, but triggering this Coverity issue), this does seem
like better behavior and more consistent with the loadfiles() implementation.

The use from addfiles.js (the -readd option) implies this is what's expected.
And echicken was suprised the 'added' date/time-stamp wasn't udpated.

Nobody's really using this auxdata yet, besides echicken, so no impact for
others.

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.