Skip to content
Snippets Groups Projects
  1. Jan 14, 2025
  2. Jan 11, 2025
  3. Jan 06, 2025
  4. Dec 21, 2024
    • Rob Swindell's avatar
      Encode local wallclock (not time_t) in SMB's when_t.time · 445394f9
      Rob Swindell authored
      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.
      445394f9
  5. Dec 14, 2024
  6. Dec 10, 2024
    • Rob Swindell's avatar
      If user doesn't modify the replied-to-msg subject, use the original subject · 69111a8f
      Rob Swindell authored
      (which might be UTF-8 encoded). This works-around the problem that Accession
      reported in #synchronet with my reply to a UTF-8 encoded message using a CP437
      terminal which resulted in a message body that was UTF-8 encoded but a message
      subject that was CP437 encoded. This mix of encodings is not supported by FTN
      standards.
      
      This is just a work-around since if the user modifies the subject the result
      could still have the CP437 unside-down question marks (indicating
      non-translatable UNICODE chars) and those should be converted to UTF-8
      chars when going out on FTN or being stored in the message base. So there's
      still a bug here somewhere that I need to look into more.
      69111a8f
  7. Dec 02, 2024
  8. Nov 26, 2024
    • Rob Swindell's avatar
      Create/use SysopPageNotification text.dat string · 0dc160f0
      Rob Swindell authored
      to notify sysop (user #1) that they were paged. Previously, this was
      a hard-coded string. The new string in text.dat is the same, but adds
      2 BELs (CTRL-G chars) and is now customizable.
      
      Created an sbbs_t::notify() method to make this easier to use and that
      method supports @-code expansion, so this text.dat string supports @-codes
      (which I used).
      
      This addresses the feature request in issue #828 (beep the sysop in the
      telegram/short message, when they're paged).
      0dc160f0
  9. Sep 07, 2024
  10. May 16, 2024
  11. Feb 16, 2024
    • Rob Swindell's avatar
      UTF-8 improvements · 2584a864
      Rob Swindell authored
      Don't corrupt UTF-8 strings with SAFECOPY() (use new SAFECOPY_UTF8).
      
      Some terminals (notably, Windows Terminal) display zero width UNICODE chars
      as a single column-wide space. <sigh> Auto-detect the zero-width "width"
      (1 or 0) of the terminal during connection and UTF-8 auto-detection.
      
      getstr() works a lot better now with UTF-8 strings with wide chars (e.g.
      emojis), but likely much more to do.
      2584a864
  12. Jan 15, 2024
    • Rob Swindell's avatar
      Don't expand @-codes automatically for all node messages/telegrams saved · 839c3a31
      Rob Swindell authored
      This recent enhancement (Commit 61a3ab2d) introduced security and usability
      concerns.
      
      So I created (and am now using where requested) a wrapper for formatting
      text.dat/ini strings which will automaticlaly detect @-code encoded strings
      and expand/use them *only* (instead of printf %-specifiers).
      
      This might impact issue #696 since although unintentionally, it actually was
      possible to mix @-codes and %-specifier usage in certain (node status)
      text.dat/ini strings, but that should not be possible now. It's either/or:
      @-codes or %-specifiers, not both.
      839c3a31
  13. Dec 12, 2023
    • Rob Swindell's avatar
      Fix the @-code support in the Regarding* text.dat strings · a31f4346
      Rob Swindell authored
      Actually tested myself this time, needed a lot more than first appearances.
      
      Also includes a security/safety enhancement where the @-code expanded string
      is *not* used as an sprintf format string. Supporting both format specifiers
      and @-codes in a single text.dat string is tricky (always has been).
      
      For Accession.
      a31f4346
  14. Dec 10, 2023
    • Rob Swindell's avatar
      Support @-codes in Regarding* text.dat strings · ef13f35c
      Rob Swindell authored
      Expected to use the MSG_* @-codes in this context. This allows more freedom
      of ordering the message header fields reused in this expanded string. The %s
      specifiers can be eliminated altogether when using @-codes.
      
      For Accession to play with.
      ef13f35c
  15. Nov 22, 2023
  16. Jun 09, 2023
    • Rob Swindell's avatar
      <Deuce> ... billion-and-one result of comparison of constant 100000 warnings. · 2b087b8b
      Rob Swindell authored
      So Clang-FreeBSD was warning (in compiles of scfg/scfg*.c by Deuce):
      result of comparison of constant 100000 with expression of type 'uint16_t'
      (aka 'unsigned short') is always true
      
      Why? Cause a uint16_t's max value is 65535 (less than 100000). Sure we could
      have just lowered the UIFC max number of config items to 65535, but that would
      have been too easy. And why are these compared-with values of type uint16_t to
      begin with? Because most ctrl/*.cnf lists (of configuration items) were
      limited to 65535 entries cause ... 16-bit DOS, historically. Now that *.cnf
      files aren't used, we could just increase these scfg_t.*_total type sizes from
      16 to 32-bits, yeah? The result is this commit.
      
      I went to (signed) int so we could still keep -1 as the special illegal
      sub/dir num value (e.g. INVALID_SUB, which is sometimes used to indicate the
      email message base). Theoretically, 2 billion configuration items could be
      supported in these lists, but SCFG will limit you to 100000 anyway. So there's
      a whole lot of s/uint/int in this commit.
      
      I'd be very surprised if this doesn't result in some new GCC/Clang warnings,
      but at least the old "comparison of constant 100000" warnings are now gone!
      2b087b8b
  17. May 24, 2023
  18. May 08, 2023
    • Rob Swindell's avatar
      Bounds-check subnum in savemsg() · 8cd6c487
      Rob Swindell authored
      It's possible to use savemsg() (from JS MsgBase.save_msg()) to add a message
      to a message base that's not a sub-board (not configured in SCFG->Message
      Areas and not the "mail" base), but in that case, savemsg() would dereference
      an invalid sub in the scfg->sub array and crash. So use is_valid_subum()
      to insure the subnum is a valid sub before using as an index.
      8cd6c487
  19. Feb 19, 2023
    • Rob Swindell's avatar
      The great 'long int' purge of 2023 part 1 · 59d8974c
      Rob Swindell authored
      At one time, Synchronet was a 16-bit DOS project, plagued by the 16-bit [u]int, so long's were used everywhere > 16-bits were known to be needed/wanted (This is before the days of the standard sized types from stdint.h), and they've persisted.
      
      But '[u]long int' is 64-bits on *nix 64-bit builds, 32-bits everywhere else (even 64-bit Windows builds if/when we ever get around to that), so this could lead to insidious bugs that would only show up on one flavor or the other. Since [u]int is 32-bits on everything we currently support, we'll use that instead of [u]long.
      
      This "part 1" because I'm sure there's going to be warnings and errors from the GCC/Clang builds as a result, which I'll get to next.
      59d8974c
  20. Jan 30, 2023
    • Rob Swindell's avatar
      The 3rd great MQTT data scheme update (sorry Nelgin) · e94281e6
      Rob Swindell authored
      - Most published messages (besides log entries) have a timestamp (in ISO8601 format) prepended and tab-separated
      - The order and number of elements in client messages (list and activities) has been updated, now includes user number
      - Server client lists are now published to .../SERVER/client/list
      - Server client activities (connect, disconnect, update) are now published to .../SERVER/client/action/#
      - Server client count is now published to .../SERVER/client (with the maximum client count, if applicable)
      - Server states are now just represented by name (e.g. initializing, ready, stopping, stopped) and not number
      - BBS errors are logged to sbbs/BBS/action/error/LEVEL (where LEVEL is the log level name, e.g. "critical" or "error')
      - All server hack-attempts, SPAM attempts, logins, logouts, uploads, downloads, are published to sbbs/BBS/action/ACTION/*
      - Chat pages are published to sbbs/BBS/action/page/node/#
      - New users (on the terminal server) are published to sbbs/BBS/action/newuser
      - Posted messages and executed external programs (on the terminal server) are published to sbbs/BBS/action/ACTION/CODE topic
      - The event thread started/stopped status is published to .../SERVER/event
      
      Yeah, the wiki will get updated soon to reflect/document all these changes
      e94281e6
  21. Jan 24, 2023
  22. Oct 24, 2022
  23. Oct 18, 2022
    • Rob Swindell's avatar
      Full read/write support of new user.tab userbase file · 8a22b246
      Rob Swindell authored
      Also resolved some 32 vs 64-bit 'long' issues/ambiguities that have long-remained. :-)
      
      This commit also removes logon.lst file support.
      
      There's a TODO block remaining in js_user.c for setting portions of a user's birthdate (e.g. just the year or month or day).
      8a22b246
  24. Mar 10, 2022
  25. Apr 14, 2021
    • Rob Swindell's avatar
      Debug the "thread_back field missing" error · dbed82c6
      Rob Swindell authored
      Some QWKnet vote messages are failing:
      evnt unpackREP <ENSEMBLE> !ERROR 2 (No such file or directory) in qwk.cpp line 1146 (qwk_vote) writing "/sbbs/data/subs/dove-gen" access=-105 info=smb_addvote thread_back field missing
      
      Catch this problem a little higher up (in votemsg()) and log the message's reply-IDs to help determine what's the root-cause here. Don't bother calling smb_addvote() if thread_back is 0.
      dbed82c6
  26. Apr 04, 2021
  27. Mar 19, 2021
  28. Nov 12, 2020
    • Rob Swindell's avatar
      Reduce unnecessary posted-to username searches. Auto-UTF8 in savemsg(). · 1060bd21
      Rob Swindell authored
      When posting to "All" or replying to a message that was posted by networked (not local) user, don't attempt to search for that username in the local user base to inform them of the posted message to them.
      
      savemsg() is the underlying C function for saving a new message (mail or post) to a message base from several places, including JS modules. If there was no "charset" specified in the passed message header, check to see if the message body text is non-ASCII but valid UTF-8, and if it is, set the FIDO_CHARSET header field to the appropriate UTF-8 charset identifier string. This would *also* address Issue #177 reported by Michael J. Ryan. It's possible, but unlikely, that a message text would contain valid CP437 that *also* happened to be valid UTF-8. If that does happen to occur (e.g. in posted ANSI art?), we might want to revert this enhancement to savemsg() and leave to the caller's to detect/specify the charset, always.
      1060bd21
  29. Oct 22, 2020
  30. Oct 03, 2020
  31. Oct 01, 2020
    • Rob Swindell's avatar
      Resolve a gcc warning about signedness. · f3588d32
      Rob Swindell authored
      f3588d32
    • Rob Swindell's avatar
      Notify local recipients of locally-posted messages addressed to them. · dd8c9620
      Rob Swindell authored
      While SBBSecho would notify local users of imported messages addressed to
      them (both EchoMail and NetMail) and QWK-imported messages recently gained
      the ability to notify local recipients of messages addressed to them, other
      methods of posting messages (e.g. just using the normal terminal server
      method, e.g. the 'P' command) or using any JavaScript (e.g. web) methods of
      posting messages lacked recipient notifications. So that's now fixed.
      And for JavaScript-saved local email messages too. I don't *think* this will
      result in any duplicate notifications of received messages, but let me know
      if you see excess/duplicate notifications.
      Anonymously posted messages are excluded.
      Messages posted to yourself are excluded (who does that?).
      dd8c9620
  32. Sep 07, 2020
    • Rob Swindell's avatar
      Fix observed race-condition resulting in the HOSTNAME @-code being blank. · dee21ed6
      Rob Swindell authored
      Eliminate the hack in each server where it will over-write startup host_name
      (with the configured Internet email address), if it's blank. This hack was
      subject to a race condition where the parent app (e.g. sbbsctrl.exe) would
      clear or re-initialize the host_name after the sever threads had initialized.
      Instead, just use a function which will return either the startup->host_name
      or (fallback to) scfg.inet_addr.
      dee21ed6
  33. Aug 16, 2020
  34. Aug 15, 2020
  35. Aug 08, 2020
    • rswindell's avatar
      The problem: the sysop (me) is not notified of critical errors (e.g.... · 5899a303
      rswindell authored
      The problem: the sysop (me) is not notified of critical errors (e.g. synchro.net zone file problems) in a timely manner.
      Part of the solution: notify a configured user (e.g. user #1) via short-message/telegram and email/netmail logged-errors when messages of a configured severity (e.g. "Critical") are logged.
      The second part of the solution (coming next) will be allowing timed events to log a message of a configurable severity logged when the event fails (returns a non-zero error level to sbbs).
      
      I'm saving the error-notification-user-number and log-severity as part of the node.cnf file because:
      - that's where the validation user number is already set
      - I can conceive of a large system were certain node ranges (different instances of sbbs) might want different operators to be notified of logged-errors
      
      This also means I eliminated all the legacy com port/modem stuff from the end of the node.cnf file. None of that is used in sbbs v3.
      
      Also included in this commit are improvements around logging:
      - reduce the severity of UDP recvfrom failures in services
      - a more detailed log message when the mail server successfully delivers an email (via SMTP) - easier to answer the question: was that email you/they sent delivered successfully?
      5899a303
  36. May 25, 2020
Loading