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

  • src/sbbs3/sbbsecho.c

    From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Sun Nov 10 17:15:21 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/3c0a335de3ba7d0008134bd1
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Log a notice-level message when renaming a bad bundle file to *.?_? or *.?-?

    ---
    þ 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 Tue Nov 12 20:08:03 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/fb138db6799daa4722bc8689
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Support multiple filenames in subjects of file-attach netmails being packed

    When writing the attached file path/names to the FLO file, parse each
    filename out of the subject, accordingly. This should fix issue #824.

    There's an inconsistent support in SBBSecho for FileLists in the subjects of netmail messages. In a couple of places, single-space-separated filelists are fine (but not commas or multiple space, even though they are allowed per FTS-1).

    This particular fix is just for the packing of netmail messages and the appending the attached file(s) to the FLO file. Those other places (e.g.
    .REQ file creation) will need their own fixes for proper filelist support.

    ---
    þ 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 Tue Nov 12 21:11:32 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/25ed5ec70838f530e7fc04ba
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Support multiple files ("FileList" per FTS-1) in subj when creating .REQ files

    Previously, this feature assumed just one request per FREQ message, however FTS-1 make this clear:

    If one or more of FileAttached, FileRequest, or FileUpdateReq are
    asserted in an AttributeWord, the subject{72} field is interpreted as
    a list of file specifications which may include wildcards and other
    system-dependent data. This list is of the form

    FileList = [ FileSpec { Sep FileSpec } ] Null

    FileSpec = (* implementation dependent file specification. may
    not contain Null or any of the characters in Sep. *)

    Sep = ( " " | "," ) { " " }

    ---
    þ 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 Sat Nov 16 14:05:33 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/e55183c0953d0b033d9f1179
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Use fmutex_open for 100% locking and auto-removal upon close/termination

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on ChromeOS)@VERT to Git commit to main/sbbs/master on Sun Nov 17 16:40:39 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/dbf5e7758f297321c0b5260d
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Revert "Use fmutex_open for 100% locking and auto-removal upon close/termination"

    This reverts commit e55183c0953d0b033d9f11796f4290e488596e92.

    fmutex_open()'s auto-remove feature doesn't work on normal/local Linux file systems: unlink() of a file immediately removes its directory entry allowing subsequent opens of the same file name, defeating the lock.

    I had tested fmutex_open() on a Samba mount (from Linux) and it worked as I wanted (like the Windows version does). Still searching for a good solution:
    if a process terminates, gracefully or not, I'd like the file to be removed
    at that time and until then, other processes or threads can't create or open the same lock file (using O_EXCL and file locking to insure this).

    ---
    þ 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 Wed Nov 20 14:45:07 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/3f24e009942a2d66c1870f34
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Fix new potential NULL derefs (the add/del_area args can be NULL)

    ... in area manager code modified in previous commit.

    ---
    þ 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 Wed Nov 20 14:45:07 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/a8cf36696b038fc4815f1264
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Fix unsigned compare against >= 0 and nomatch misplacement

    I'm not clear if/why these would cause the issue reporetd by
    Fernando but they're definitely bugs in the areas.ini areafix
    code. No impact to the areas.bbs areafix handling.

    ---
    þ 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 Wed Nov 20 20:50:41 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/a225fd20b4236ff5f8f56cc5
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Detect and log warnings about duplicate area sections in areas.ini

    ... like how we do for areas.bbs files.

    ---
    þ 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 Wed Nov 20 20:50:41 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/6c85be290b34f6379cf56fe1
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Support AreaMgr request messages with -L (list) or -Q (query) but no body

    I noticed through code review that these kinds of messages would be rejected
    as "No commands to process.". We just needed to increment the 'cmd' counter when parsing these options to be sure we don't think that no commands were
    in fact request. -R (rescan) is not by itself a command since it requires listed area-tags to have any effect.

    ---
    þ 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 Wed Nov 20 20:50:41 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/f37c0346b645496e4e591d10
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Fix stupid inverted logic bug: treating areas.ini as areas.bbs for AreaFix

    and vice versa - so area manager requests were broken since I introduced the areas.ini support. Oops.

    ---
    þ 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 Fri Nov 22 17:50:50 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/2382d2987953d948a56b7612
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Clean up area management code

    I dislike this particular code a little less now:
    - no more redundant string compares
    - less deeply nested if() and for() blocks
    - remove added areas from the add list, rather than zeroing out the tag
    - a little more common code between areas.bbs and areas.ini handling

    No functional change (I hope).

    ---
    þ 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 Sat Nov 30 21:02:49 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/cee11a4e100dba897abc250c
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Eliminate some harmless gcc warning about using uninitialized vars

    ---
    þ 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 Thu Dec 5 21:40:24 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/1520bba8c23f3e6b5d80de7f
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Truncate the GIT date (remove time) in Program ID.

    ---
    þ 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 Fri Dec 6 17:38:28 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/e2476ebbaa0a7d05e72bce2d
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Fix insufficient allocation bug in link_area() introduced in commit 813072cd4

    This is likely the cause of the areamgr issue that resulted in weird/invalid node address being added to the area file, reported by Tom Moore (1:135/205).

    ---
    þ 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 Sat Dec 7 14:08:12 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/c14cea13c153d2e18455823f
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    A differnt 'fix' to link_area()

    So, (sizeof *addr) now looks right got me (this should've been the same as sizeof(fidoaddr_t)), so the change in commit e2476ebbaa doesn't actually look like a fix, but maybee a regression.

    I need to test some area manager link additions and get to the bottom of this, but this particular change was not a fix (and caught/reported by Coverity -
    CID 515673).

    ---
    þ 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 Sat Dec 7 16:39:06 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/68e76982e0054dffec75b75c
    Modified Files:
    src/sbbs3/sbbsecho.c
    Log Message:
    Fix the areas.bbs AreaMgr addition bug created in commit 813072cd450c2

    The newly created/used link_aera() function was copying the address of the passed fidoaddr_t pointer rather than the value (fidoaddr) pointed to.
    This is the actual fix for the problem reported by Tom Moore (1:135/205)
    - tested and validated. It only immediately impacted areas.bbs use
    (not areas.ini), since we wrote a stringified address directly to the
    areas.ini file "links" key. This was not an allocation issue but a memcpy() issue.

    Other unrelated changes:
    - Log a debug-level message when ignoring a "NO-ECHO" message (subject "NE:*") - Log a notice-level message when ignoring a message due to GATEWAY VIOLATION
    (gating a message between net-types when not explicitly configured to do so)

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