Need to unlock the mutex before calling errormsg().

Need unlock the mutex in error path of unlocknodedat().

I'm not clear why this would, but it might resolve CID 515601 which looks
like false positive to me: getnmsg()->putnodedat() should never leave
nodefile_mutex locked.

Resolves CID 515657

I don't think this was actually a leak (since smb.msgs should be non-zero
any time mail is non-null), but to make Coverity happy (CID 515659) and just
be more fault-tolerant, always free(mail).

DDMsgReader: Screen refresh fix for selecting messages when automatically moving to the next message at the menu's last row on the screen

See merge request !481

DDMsgReader: Screen refresh fix for selecting messages when automatically moving to the next message at the menu's last row on the screen

Should be possible to implement the hard stuff now, though it won't
actually be testable until the KEX bits exist too.

Smooth sailing after that though.

If the path already exists (is a directory), don't need to check each path
element for existence.

This should help with the speed of saving of large file.ini (Nelgin's) when a
lot of directories have "Check for File Existence" set to "Yes".

(128 bytes)

Fix up the filename in error messages reported during unpacking QWK packets
(MESSAGES.DAT not BBSID.QWK).

Convert more log messages to use de-duplication as solution to issue #619.

A lot more lprintf() -> errprintf() conversions will be needed to fully
realize this solution (e.g. in the mail, ftp, web, services serverss).

In printfile() and printtail() which are used by menu() and many other
functions.

These should be helpful to sysops that just want to know what file is being
displayed under what conditions (e.g. for trouble-shooting or customization
reasons).

Other kinds of aliases are supported in web_alias.ini (e.g. libraries, files)
but not displaying those here (yet).

... instead of just the file name, as was expected.

This is why files downloaded via ecWebv4 haven't been properly accounted.

Under heavy loads, I've found periodic non-blocking lock attempts just aren't
reliable enough: in particular, on Vertrauen, the guest user account record
in the user.tab file gets read and written-to A LOT (updating stats), and
under heavy loads (especially with hundreds of web client sessions), I'd get
timeouts attempting to lock the guest record in the user.tab (after about a
minute of periodic retries) - so let's just block "forever" to get the user
record lock (or until signaled or notified of a deadlock). With this change,
I've not had any user.tab lock errors or apparent deadlocks.

Let the underlying OS/filesystem handle queuing and deadlock detection,
when supported. lock() still behaves as before: non-blocking lock attempt.

DDMsgReader: Bug fix - For indexed newscan without snap-to-new, ensure it remembers the user's previously selected sub-board (reported by Keyop)

See merge request !480

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

DDMsgReader: Bug fix - For indexed newscan without snap-to-new, ensure it remembers the user's previously selected sub-board (reported by Keyop)

- If sysop specifies an invalid lib name, show them what the valid names are
- Make it clear that the directory specified (dir-spec) is either a combination
  of -lib and -dir *or* -all *or* dir-code *or* nothing (a get prompted)
- When using -all, clear the list of specified directories to prevent dupe
  dir scanning when misused.

As requested by Nelgin.

And this option is mutually exclusive with the [dir-code] parameter.

... from ERROR to WARNING, so the repeats won't be logged to error.log file
and won't (normally) be sent as notifications (e.g. emails) to the sysop. The
duplicates are identified as from the same source file and line number as the
immediately previous logged error within the last 12 hours. String comparison
doesn't really work for deduplication since if you look closely, the errors
usually are *not* exact duplicates (i.e. there's a node number or a socket
descriptor or something that uniquely identifies the user/client/session).
Repeated errors don't increment the node's error counter either.

This does not de-duplicate errors logged via other means (e.g. direct calls to
log()/lputs(),lprintf() with a severity of LOG_ERR or higher), but will
solve the majority of duplicate errors that can be logged from the terminal
server.

So this at least partially addresses issue #619.

Next step is to implement a KEX.

With this, SyncTERM and SexPOTS on *nix won't actually need to strip
received bytes themselves.  No idea what Windows does though, so
it'll likely still be needed forever.

DDMsgReader: New user option & behavior: In a message list, when selecting/toggling a message, it can now optionally move the cursor to the next message

See merge request !479

DDMsgReader: New user option & behavior: In a message list, when selecting/toggling a message, it can now optionally move the cursor to the next message

This happened to work before commit d49134e6 since iniReadFile()
didn't return false upon any read error, so File.iniSetAllObjects() didn't
realize that the read of (any) existing file contents had failed (because the
file was open write-only).

This explains why the *.avatars.ini files were pretty much blank as of late
and no networked message posters were having their avatars displayed.
Reported by Codefenix (thank you).

Add a print/log line to tell us how many avatars were parsed, just for extra
traceability of this script and any potential failure cause.

The plan is to hide non-standard stuff in here.  Currently, just
has [[maybe-unused]] from C23.