1. Forum
  2. Fidonet
  3. SYNC PROGRAMMING

  • src/sbbs3/sbbsecho.c

    From Rob Swindell (on Windows 11)@1:103/705 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 *.?-? --- SBBSecho 3.21-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 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.
    --- SBBSecho 3.21-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 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 = ( " " | "," ) { " " }
    --- SBBSecho 3.21-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell (on Debian Linux)@1:103/705 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
    --- SBBSecho 3.22-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell (on ChromeOS)@1:103/705 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).
    --- SBBSecho 3.22-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell (on Debian Linux)@1:103/705 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.
    --- SBBSecho 3.23-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell (on Debian Linux)@1:103/705 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.
    --- SBBSecho 3.23-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell (on Debian Linux)@1:103/705 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.
    --- SBBSecho 3.23-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell (on Debian Linux)@1:103/705 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.
    --- SBBSecho 3.23-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell (on Debian Linux)@1:103/705 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.
    --- SBBSecho 3.23-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell (on Debian Linux)@1:103/705 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).
    --- SBBSecho 3.23-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)