1. Forum
  2. FidoNet
  3. SYNC PROGRAMMING

  • src/sbbs3/smbutil.c

    From Rob Swindell (on Debian Linux)@1:103/705 to Git commit to main/sbbs/master on Fri Jan 16 20:16:08 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/783f80855c13873c76054e26
    Modified Files:
    src/sbbs3/smbutil.c
    Log Message:
    Fix index corruption resulting from packing an unmaintained msg base

    and filebase corruption.

    Bug was introduce in v3.19 with the filebase support:
    - we were assuming the newly packed (rebuilt) index had the same record offsets
    as the original/source index (if any records are skipped, e.g. because they
    are deleted, they offsets aren't the same, so you end up with an index (.sid)
    file that's too big and thus fails chksmb verification
    - we weren't reading the entire file base index record so packing a filebase
    would corrupt the index

    Bumped version to 3.21
    --- SBBSecho 3.34-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell (on Windows 11)@1:103/705 to Git commit to main/sbbs/master on Fri Feb 13 00:34:20 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/c322f624d537025462d70da5
    Modified Files:
    src/sbbs3/smbutil.c
    Log Message:
    Rename msgbase files *before* packing to insure exclusive access

    Even with the *.lock file created exclusively, there's still a race condition where other processes could have the msgbase files open in which case the
    final rename (e.g. from *.sd$ to *.sdt) would fail with an error and you'd end up with a mix of files from before and after the pack operation.

    This rename-first operation insures we're the only ones with the msgbase open and since we have it locked, no one else should be able to open subsequently either.

    Updated the temp filename extenions to 4 chars now, so the operation goes like this:

    ren pack ren
    [*.shd/sdt/sid] -> [*.shd_/sdt_/sid_] -> [*.shd$/sdt$/sid$] -> [*.shd/sdt/sid]

    Commented out the "duplicate index" message which was wrong (it's the header that's duplicate, not the index) and a perfectly normal situation for mail
    msgs to multiple recipients.
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)