1. Forum
  2. DOVE-Net
  3. Synchronet Programming

  • src/sbbs3/smbutil.c

    From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Friday, January 16, 2026 20:16:08
    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

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Friday, February 13, 2026 00:34:20
    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.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Wednesday, May 06, 2026 22:36:56
    https://gitlab.synchro.net/main/sbbs/-/commit/1fbe29cb3c13f8878731477d
    Modified Files:
    src/sbbs3/smbutil.c
    Log Message:
    smbutil: free idxbuf and unlock smbhdr on terminated abort in maint() (CID 644892)

    Five 'if (terminated) return;' sites in maint() leaked idxbuf (heap)
    and left the SMB header lock held. The deletion-execution loop also
    left the SMB-allocation file handles open. Mirror the existing
    "nothing to delete" cleanup before each early return.

    Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Wednesday, May 06, 2026 22:36:57
    https://gitlab.synchro.net/main/sbbs/-/commit/7506c7bf8670aeacf982f282
    Modified Files:
    src/sbbs3/smbutil.c
    Log Message:
    smbutil: free datoffset on fread early-return in packmsgs() (CID 462184)

    Three bare 'return;' statements after the smb-header-rewrite reads
    leaked datoffset (allocated just above for the per-msg offset map).
    Free it before returning. Other resources at these sites (tmp file
    handles, smb header lock) are pre-existing leaks that Coverity did
    not flag and are out of scope for this CID.

    Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Thursday, September 24, 2026 21:22:49
    https://gitlab.synchro.net/main/sbbs/-/commit/893817954cb42bd437b8c796
    Modified Files:
    src/sbbs3/smbutil.c
    Log Message:
    smbutil pack: free the space of a message it drops

    When pack drops a message whose data it can't copy, or for which it can't allocate a header, the data space already allocated for it in the packed
    base was left allocated with nothing referencing it: blocks lost until the
    next pack. Both skip paths were added by aee485f478 (reducing-28-isle, 2026-09-15).

    Pack only appends to the new .sdt and .sda, so the dropped message's data
    is always the last allocation in each; pack_drop_dat() truncates both back
    to where it started. smb_freemsgdat() isn't usable mid-pack: it unlocks
    the SMB header pack holds, and it truncates smb.sdt_fp, which is the
    original data file being read.

    For data shared with an earlier index, the extra reference is now added
    only once the header is allocated, so a header failure leaves nothing to
    undo.

    Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net