1. 21 Nov, 2016 6 commits
  2. 20 Nov, 2016 8 commits
    • rswindell's avatar
      Fix new bug reported by DesotoFireflite: · 64e9e828
      rswindell authored
      ERROR 2 (...) opening "...HEADERS.DAT" when importing QWK packets that
      including a VOTING.DAT file.
      64e9e828
    • rswindell's avatar
    • rswindell's avatar
      VOTING.DAT Backwards-compatibility enhancement: · 8dd3b13e
      rswindell authored
      If a VOTING.DAT file is received which did not contain offset/location
      sections, the vote/polls/etc. wouldn't be imported. Now, when each QWK 'V'
      msg hdr block is imported, the corresponding section is removed from the
      VOTING.DAT and after all QWK importing, the VOTING.DAT is then parsed
      for remaining items/sections and if there are any, imported at that time (in
      order in the file, not in the old poll/vote/closure order).
      8dd3b13e
    • rswindell's avatar
      Solved the networked-voting "ordering problem". QWK/REP packets that contained · 3258eca3
      rswindell authored
      normal messages along with voting data (polls, ballots, etc.) would always be
      imported in this order: msgs, polls, ballots/votes, and then poll-closures.
      This could result in a confusing order of messages in the local msg base where
      there were messages in reply to a poll before the poll appears and other
      oddities. Anyway, this is now resolved by placing a msg "header block" for each
      vote-data item in the MESSAGES.DAT file. Since there is no body/text blocks,
      it should be ignored under normal circumstances, but these header blocks are
      only created if VOTING.DAT is enabled anyway.
      And now, the VOTING.DAT contains an extra line (empty .ini section) with the
      HEADERS.DAT offset associated with the chronology of the item. The format
      is still backwards compatible with the earlier builds that included VOTING.DAT
      support.
      
      Also, fixed the vote/poll/closure Message-IDs containing a msg number of 0
      (while not technically a problem, it wasn't the intention) with the use of the
      new function: get_new_msg_number().
      3258eca3
    • rswindell's avatar
    • nightfox's avatar
      Version 1.17 Beta 1: Implemented a workaround for handling message headers... · 958d5f18
      nightfox authored
      Version 1.17 Beta 1: Implemented a workaround for handling message headers that are null (which are more common now with the message voting feature recently introduced in Synchronet).  Now such message headers won't cause weirdness in the message list.  Users won't be able to read such messages.  I'd like to find a way to not show such messages altogether in the message list - Will probably need to use the get_all_msg_headers() method in the MsgBase class to get all message headers except ones for vote messages.
      958d5f18
    • rswindell's avatar
      Fix bug importing polls from QWK/REP packets: · 7fb73c67
      rswindell authored
      "Subject" wasn't being parsed from VOTING.DAT and is a required header field
      for polls, causing error: qwk.cpp line 1149 writing "/sbbs/data/subs/dove-sys"
      access=-105, as reported by echickenster.
      7fb73c67
    • rswindell's avatar
      Automatic REPLY-ID fixup: · 396b931b
      rswindell authored
      If a message header has a thread_back value (it's a reply to another msg), but
      there is no Reply-ID header field, when converting QWK, look-up the
      original message-ID (to use for the relpy/vote Reply-ID value). If the original
      message doesn't have a message-ID, use the normal auto-generation scheme.
      This isn't normally necessary, but I posted a poll with a message-ID on
      DOVE-Net / Sysops and then voted on the poll, creating a vote with no Reply-ID
      which causes an SMB "writing" error (access=-105) on the QWKnet node BBSes
      (because the required header field is missing).
      396b931b
  3. 19 Nov, 2016 11 commits
  4. 18 Nov, 2016 14 commits
  5. 17 Nov, 2016 1 commit
    • rswindell's avatar
      Fix getuserdat() bug introduced in rev 1.164: when failing to read a user · 6e7bf768
      rswindell authored
      record (e.g. the user number is invalid), the user number should be 0 after
      returning. This would cause, for example, sbbs_t::login() to accept a login
      string with an invalid usernumber (e.g. "12345") and do some strange things.
      The same side-effect was missing in the (new) fgetuserdat().
      6e7bf768