The newly created/used link_aera() function was copying the address of the
passed fidoaddr_t pointer rather than the value (fidoaddr) pointed to.
This is the actual fix for the problem reported by Tom Moore (1:135/205)
- tested and validated. It only immediately impacted areas.bbs use
(not areas.ini), since we wrote a stringified address directly to the
areas.ini file "links" key. This was not an allocation issue but a memcpy()
issue.

Other unrelated changes:
- Log a debug-level message when ignoring a "NO-ECHO" message (subject "NE:*")
- Log a notice-level message when ignoring a message due to GATEWAY VIOLATION
  (gating a message between net-types when not explicitly configured to do so)

So, (sizeof *addr) now looks right got me (this should've been the same as
sizeof(fidoaddr_t)), so the change in commit e2476ebb doesn't actually look
like a fix, but maybee a regression.

I need to test some area manager link additions and get to the bottom of this,
but this particular change was not a fix (and caught/reported by Coverity -
CID 515673).

This is not the "hard part" I meantioned earlier. :D

This is likely the cause of the areamgr issue that resulted in weird/invalid
node address being added to the area file, reported by Tom Moore (1:135/205).

There still appears to be some race condition with network (Samba) FS
directory caching and opening/locking of files, so it does seem illogical that
the packet file wouldn't exist at this point (since we have the lock file
opened) but this does still happen on occasion on Vertrauen.

A negative timeout value doesn't make sense and this will extend the legal
(positive) range of this parameter value.

Hopefully this will help eliminate these errors I get often:
  dd_lightbar_menu.js line 4041: Error: can't convert inputTimeoutMS to an
  integer

But if there's some way that this parameter value is even out of the range of
an unsigned 32-bit value (4294967295) then this error could still happen.
Unfortunately, the JS exception doesn't report the value that failed to
convert.

Should fix CID 515599 since this seems to be the only place we call
unlocknodedat() without possibly not owning the nodefile_mutex already.

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.