Skip to content
Snippets Groups Projects
Select Git revision
  • dailybuild_linux-x64
  • dailybuild_win32
  • master default protected
  • sqlite
  • rip_abstraction
  • dailybuild_macos-armv8
  • dd_file_lister_filanem_in_desc_color
  • mode7
  • dd_msg_reader_are_you_there_warning_improvement
  • c23-playing
  • syncterm-1.3
  • syncterm-1.2
  • test-build
  • hide_remote_connection_with_telgate
  • 638-can-t-control-c-during-a-file-search
  • add_body_to_pager_email
  • mingw32-build
  • cryptlib-3.4.7
  • ree/mastermind
  • new_user_dat
  • sbbs320d
  • syncterm-1.6
  • syncterm-1.5
  • syncterm-1.4
  • sbbs320b
  • syncterm-1.3
  • syncterm-1.2
  • syncterm-1.2rc6
  • syncterm-1.2rc5
  • push
  • syncterm-1.2rc4
  • syncterm-1.2rc2
  • syncterm-1.2rc1
  • sbbs319b
  • sbbs318b
  • goodbuild_linux-x64_Sep-01-2020
  • goodbuild_win32_Sep-01-2020
  • goodbuild_linux-x64_Aug-31-2020
  • goodbuild_win32_Aug-31-2020
  • goodbuild_win32_Aug-30-2020
40 results

sbbs

  • Clone with SSH
  • Clone with HTTPS
  • Rob Swindell (on Windows)'s avatar
    Rob Swindell authored
    When bad packets are detected and renamed to ".bad" files, include the reason
    in the new filename (e.g. "ff69453a.src-addr.bad" or "ff69453a.pkt-passwd.bad"
    instead of just "ff69453a.bad") to make it easier for a sysop to determine
    what to do with the bad packets without having to search through log files
    to discover the reason *why* SBBSecho considered the packet to be bad.
    This behavior can be disabled if desired by setting EchoCfg->Global->Verbose
    Bad Packet Names to "No". Note: the reason used is the *last* reason
    detected/logged for a packet to be considered bad; it's possible that there
    are multiple reasons that a packet may be considered bad. All reasons will be
    logged, but only the last reason is used in the new bad packet filename.
    
    Also added the missing "Delete Packets" option (to EchoCfg->Global). Though
    this setting was added in sbbsecho v3.0 (and settable via sbbsecho.ini), it
    was never exposed via EchoCfg; I don't think that was intentional. Normally,
    you'd always want to leave this set to Yes (the default) to delete processed
    packets, but when debugging, it may be desirable to leave the packet files
    in place. This what the old sbbbsecho v2 '-x' command-line option used to be
    used for (disable the deleting of processed packets).
    
    Moved the Global Settings, EchoMail Settings, and File Paths config menus to
    the upper left of the screen in EchoCfg. The placement seemed inconsistent
    and erratic, so this is a bit of a cosmetic improvement.
    9a253736
    History
    Name Last commit Last update