1. 29 Nov, 2020 2 commits
  2. 28 Nov, 2020 14 commits
  3. 27 Nov, 2020 7 commits
    • Rob Swindell's avatar
      Include file/progress byte-offset at the beginning of log messages · 8a4698c5
      Rob Swindell authored
      Makes easier trace/debugging of issues (e.g. matching up with sending side logs).
      No functional change.
    • Rob Swindell's avatar
      Fix build error introduce in previous commit. · 6ffdef9f
      Rob Swindell authored
      __FUNCTION__ cannot be used a string literal in GCC.
    • Rob Swindell's avatar
      zmodem_recv_files() now returns upon first failed file. · df15131b
      Rob Swindell authored
      Previously, a ZRINIT frame would be sent even after a failed file download, and this could be misinterpreted by the sender as a successful file receipt 
       acknowledgement. 'lrz' just completely aborts the receive "batch" under the same conditions, so we'll just do the same to prevent the sender (e.g. BBS) from mistakenly counting this as a successful transfer (download).
      A lot of log message updates: additions, removals, and use of the __FUNCTION__ macro.
    • Deucе's avatar
      Apparently we're editing file revisions like cavemen now. · f6cc5238
      Deucе authored
      Call this one "2"
      Flashbacks to manually editing zone files here.
      I may end up going with YYYYMMDD numbers like I sometimes did in
      zone files, but maybe I'll just do the single number thing... not
      really sure yet.
    • Deucе's avatar
      "Handle" frames with a data length of zero. · d218c8de
      Deucе authored
      These frames were already not allowed in the binkp/1.0 protocol,
      and it is mentioned in the spec (issued in 2005) as "Some old
      implementations do send empty frames as the last frame.".
      It's certainly not allowed now, and any mailer which does it is
      For zero-length data packets, it will be seen as a frame containing
      zero data bytes which will also be logged as being after the file
      if it comes after the file has already been completely transferred.
      A zero-length command packet will abort with M_ERR, logging an error
      regarding command number NaN or something like that.
      This may fix #185 since attempting a recv() of zero bytes and
      succeeding is the only way I can see for a zero second timeout to
      have been logged in receving frame data.  The software assumed that
      receiving zero bytes was a timeout, but if that's what you asked for,
      it's actually success.
    • Rob Swindell's avatar
      Comment header cleanup. · a754d85c
      Rob Swindell authored
    • Rob Swindell's avatar
      Increment reported revision. · 8447edba
      Rob Swindell authored
  4. 26 Nov, 2020 10 commits
  5. 25 Nov, 2020 7 commits