With this, my fancy intro is quite usable...

Uses libjxl, makes the video demo more possible.

Does not yet have a feature test sequence, documentation, support
in the gmake build system, runtime linking, etc.  Just a quick
hack.

It also looks like I can parallize the decode, should should also
help things out.

It was badly broken, especially with large files... we now don't
try console.write() unless there's enough space in
console.output_buffer_space.

On my system (debug build of Synchronet), the most I can push through
console.write() over telnet is about 1.9MB/s.  My release build of
SyncTERM can consume about 4MB/s of string data, so Synchronet is the
choke point in my setup here. (SSH is much worse)

My super-cool demo thing ends up needing about 90 seconds to preload
all the cache stuff, so it's simply not useable, even locally. :(

If I use client.socket.send(), I can unlock the Synchronet throughput,
but I can't remember if client.socket is the passthru socket with SSH
or not... and there's no way to synchronize the socket with the console
at the end of the send (console has flush(), Socket doesn't, and even if
it did, it wouldn't flush through to the output buffer).

Check and clear/invalidate node_socket while holding the node.dab record
lock.

This should fix the error reported by kk4qnb (KK4QBN)

DDFileLister: New configuration setting: useFilenameIfNoDescription - If a description is empty, show the filename in the list instead. For Retro Guy.

See merge request !487

DDFileLister: New configuration setting: useFilenameIfNoDescription - If a description is empty, show the filename in the list instead. For Retro Guy.

DDMsgReader: An optimization for loading status, for issue #846

See merge request !486

Fix CID 516461

Fix CID 516462

DDMsgReader: When doing an indexed newscan, display the progress percentage when counting sub-boards for indexed newscan. For issue #846

Closes #846

See merge request !485

Eric Oulashin authored 3 months ago and Rob Swindell committed 3 months ago

DDMsgReader: When doing an indexed newscan, display the progress percentage when counting sub-boards for indexed newscan. For issue #846

Include O_CREAT access mode flag in opennodedat().

I experimented with excluding O_DENYNONE when the NM_CLOSENODEDAB flag is set
(to hopefully work-around MacOS Samba node.dab corruption issue), but that
didn't work with SBBSCTRL leaving the file open in SH_DENYNONE mode, so will
have revist that, but using a common open function helps.

Include a little more detail in 550 responses sent to clients too

I started seeing Windows 10.0 reported (without a build number) again on
Windows 11 (after a regular update), so changed the logic to always try/use
RtlGetVersion() except for Windows 7 where I saw it truncated the Service
Pack details.

This explains why Deon was still seeing time_t encoded time values.

This is a situation we can auto-correct and log a message when we do.

Could be helpful for debugging node status issues at some point

DDMsgReader: When doing an indexed newscan, display the progress percentage when doing the newscan. Should fix issue #846 (reported by Keyop)

Closes #846

See merge request !484

Eric Oulashin authored 3 months ago and Rob Swindell committed 3 months ago

DDMsgReader: When doing an indexed newscan, display the progress percentage when doing the newscan. Should fix issue #846 (reported by Keyop)

Adds new keys, removes old ones

Updates formatting/white-space

Bug

A non-zero exit from str_cmds.js (where this script is loaded) will terminate
the call/session. We don't need to call exit() at all from this script.

This fixes issue #848, thank you for the report

We already know such nodes are in-use, so no need to read their node.dab
record and put extra contention on the node.dab file. Hoepfully this
reduces or eliminates occurrences of the error:
    Node n status is WFC, but the node socket (s) and thread are still in use!
Though I kind of expect occurrences of "NODE STATUS FIXUP" errors to likely
return.

We could in theory just track status of nodes in memory (for those
nodes that this instance of sbbs controls), and not read the node.dab file at
all when checking those nodes' status, but:
- that would prevent out of process control of node status
  e.g. using the node utility to mark a node as offline
- we'd have to protect instance of in-memory node status checking/changing
  with a mutex

Hitting down-arrow key at a pause prompt normally displaye just one more line
of the display text/file, but if you received a node message/telegram/notice
after hitting down arrow, you'd get a screen full of text instead of just a
single (one more) line, as you wanted.

This looks to be because of the anti-recursive protection implemented in
pause() - when it calls nodesync() after the key press, that displays
node/user messages (if there are any) and if pause is called as a result
(e.g. because the line counter was already set to cause a pause after the
next line of output), it'd do nothing since that would be recursive. The fix
is to simply set the line counter as a result of the down-arrow key press
*after* the call to nodesync(), which might display multiple lines, but I
think that's fine.

Reduce the cognitive dissonance

I'm hoping this might help resolve instances where fexistcase() says a file
does not exist, but a subsequent call to fexist() says it does.

This became apparent when the the LSB of the day got set (an odd
day). Oops.

This only impacted decoding of date/time, not encoding.

Increment SMBLIB version to 3.10

Fix issue #845: Changing system/OS time zone, changes dates/times of posted
messages

Sysops and users shouldn't notice any change unless they change the time zone
of their system/OS (not accounting changes for daylight/standard time) and
the result will be that message dates appear the same after such a change.

For backward compatibily, any stored time_t's in msghdr_t.when_written.time
(i.e. all existing SMB messages) will still be decoded and displayed properly.
We detect a time_t value by the upper 6 bits being non-zero. When the upper
6 bits of a when_written.time value are zero, then we know the 'year' is
stored in the 16-bits before the when_written field (never used bits of the
netattr field, now part of the when_t structure definition) and the Month,
Day, Hour, Minute, and Second of the wallclock at the poster's site are
encoded in the low 26 bits of the time field.

This also eliminates more uses of 32-bit time_t that'll likely start being
a problem 2038 and really fall over and die in 2106. At least messages'
posting dates won't have any issue now. The "when_imported" values could use
a similar treatment someday I suppose - and we could get rid of the
when_imported.zone value as its not really needed we could use those 16-bits
for the when_imported.year.

Didn't change anything with filebases (still using time_t's though the
when_written hdr field isn't used for much with regards to files).

Yes, we could have converted all imported "broken down" message dates to
UTC and continued to store them as a time_t using timegm() instead of mktime()
for conversion to time_t, and I considered that. But we would have needed to
create/use a flag in the message header to indicate such stored date/times
(since they'd have to go through different adjustment for original time zone
before display, basically reversing the logic of all the places we display the
message dates/times using localtime verus gmtime/UTC C RTL functions),
couldn't just initialize the time with a call to time() upon import of local
messages (unless the local timezone happened to be UTC). And in the end, we'd
still have a 32-bit time_t value. So this seemed the better path.

I would have liked to have stored the date fields in a more human readable
encoding (BCD or decimal, ala isoDate and isoTime_t), but I just didn't have
the spare bits in the fixed portion of message headers to be wasteful like
that.

Here's an example from smbutil v of a message header posted after this change:
  when_written     03292595 41E0 Fri Dec 20 18:22:21 2024 PST
  when_imported    6766265D 41E0 Fri Dec 20 18:22:21 2024 PST

Notice the difference in the hex encoding of the date/time between the 2
header fields: when_imported still uses time_t. The when_written.year value
isn't output here.

changed from 0 to 1:
 timeperday
 timepercall
 callsperday
 postsperday
 emailperday

There are restrictions to remove access to these features if that's what the
sysop desires.

This will allow unauthenticated mail clients to post a single message (per day)
to a sub-board, when there's a posting alias set up (sub:* in alias.cfg).

... and auto-choose the right one

Tested on Windows 11 (x64) and Windows7-32