• src/sbbs3/pack_rep.cpp

    From rswindell@1:103/705 to CVS commit on Sat Apr 7 00:18:03 2018
    src/sbbs3 pack_rep.cpp 1.47 1.48
    Update of /cvsroot/sbbs/src/sbbs3
    In directory cvs:/tmp/cvs-serv17989

    Modified Files:
    pack_rep.cpp
    Log Message:
    Resolved GCC 5.4.0 warning:
    format not a string literal and no format arguments [-Wformat-security]


    --- SBBSecho 3.04-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to Git commit to main/sbbs/master on Sun Dec 20 17:11:56 2020
    https://gitlab.synchro.net/main/sbbs/-/commit/faadb5b9bdc17be17fae8aee
    Modified Files:
    src/sbbs3/pack_rep.cpp
    Log Message:
    Fix 18 year old bug with updating/appending existing REP packets18 years, 10 months ago I introduced a bug whereby .MSG files in outgoing REP packets were *always* truncated before newly-exported messages were added. Even though the log message would say "Updating /path/to/HUBID.REP" (rather than the usual "Creating ...") it was actually truncating the .MSG file, thus discarding any existing messages that were not previously successfully sent (!). I'm not sure what the problem was I was trying to solve at the time (some "Unix .rep creation bug") - but the change I made at the time was most definitely was not the correct fix. :-(How I noticed this problem was the HEADERS.DAT Conference Number check I added to qwk_parse_header_list() back in August of 2019. I've been catching/logging those errors here on Vertrauen and collecting *.rep.bad files from occasional QWKnet node-submitted REP packets, but I didn't look into
    the cause until today: the HEADERS.DAT and VOTING.DAT files were being correctly appended even though the .MSG file was being truncated, so the files would be out-of-sync and this was the root-cause of the crossed-up message bodies/headers seen on DOVE-Net a year or more ago and apparently also the cause of occasionally lost messages from QWKnet (e.g. DOVE-Net) nodes.To trigger this bug from the node side, you'd have to create a REP packet with one
    or more message in it and then fail to send it to your hub (e.g. VERT), for any
    reason. And then when you attempt another pack/call-out, the previously packed messages would be lost and the HEADERS.DAT file would contain stale/out-of-sync
    information. To simplify things, I'm now just using fopen(..., "ab") (append, binary) - fnopen() should not be needed when opening files in the temp_dir. In append mode, no subsequent fseek(..., SEEK_END) should be needed, so don't do that. And use fprintf() for its intended purpose.
    --- SBBSecho 3.11-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to Git commit to main/sbbs/master on Sun Dec 20 21:04:25 2020
    https://gitlab.synchro.net/main/sbbs/-/commit/2ccb08c89855000e66adde6c
    Modified Files:
    src/sbbs3/pack_rep.cpp
    Log Message:
    Update to previous fix for REP packingThanks to TRMB for being the guinea pig, I see now that REP packets can't be opened in append mode because we write and then seek back and write some more in msgtoqwk(). Oops.
    --- SBBSecho 3.11-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)