https://gitlab.synchro.net/main/sbbs/-/commit/a9967b46fc2be2e0d08efb49
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix memcmp() usage problem introduced in previous commit

Caught by GCC.

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

https://gitlab.synchro.net/main/sbbs/-/commit/a1bead7cc4e295514a5c1b18
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Eliminate a large pass-struct-by-value

Caught by Coverity.

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

https://gitlab.synchro.net/main/sbbs/-/commit/160606e4ce35305a55819266
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Print error and return NULL from getfmsg() upon ftell error

Caught by Coverity - ftell[o] can return negative.

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

https://gitlab.synchro.net/main/sbbs/-/commit/f3e4a6e498c8c206e087da88
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Use SAFECAT() instead of strcat() for more safety.

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

https://gitlab.synchro.net/main/sbbs/-/commit/1031d0f6e01686c5a8dda583
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Replace tempnam() usage with the suggested mkstemp()

Since we're cleaning up warnings... this will break the Windows build for now.

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

https://gitlab.synchro.net/main/sbbs/-/commit/0f262d8ab2a6bd870adbb428
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Don't allow downlinks (AreaFix add) of our "Unknown echoes" sub-board

It was recently pointed out to me that a downlink could link to the '*' echo via Area Manager (AreaFix) request. This was not intentional.

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

https://gitlab.synchro.net/main/sbbs/-/commit/7f0390149d84d79a3b7bfb10
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Keep the same area file (areas.bbs) mode flags (permissions)

When executing area manager requests that alter the area file, the temp area file created (with mkstemp) had mode 0600 (owner read/write only). The sysop very possibly had different permission flags they want to keep for their area file, so copy the mode flags from the original area file to the temp/new area file.

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

https://gitlab.synchro.net/main/sbbs/-/commit/9a8c8e6d414c2bfe503aa841
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Microsoft doesn't have fchmod(), so use chmod() on the closed file

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

https://gitlab.synchro.net/main/sbbs/-/commit/ccc0e4019838ce4021c16b0e
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
When packing netmail (stored messages), don't discard non-zero zones

As reported by Ragnarok (DOCKSUD) via DOVE-Net, when packing (packetizing) netmail messages, the source and destination zones from the netmail header were discarded (since they are defined as "optional" in FTS-1) and the zone values were replaced with the system's primary/default zone number. If the netmail message included an INTL kludge, the source and destination zone values would be parsed from that kludge line and this issue would not be noticed.

So the fix is: Only if the netmail message header contains a source or destination zone number of 0, replace that zone with the system's primary/default zone number. As before, the INTL kludge zone information can override the header fields.

Also, there's no reason to force the point numbers from the header to zero, since if they were not valid (e.g. "fill" in the original FTS-1 specification), they would be already zero. So use the source and destination point numbers, as is, from the netmail header too (with the FMPT and TOPT kludge override support left in-tact).

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

https://gitlab.synchro.net/main/sbbs/-/commit/5012efb1eb3d2d20289a01c1
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Log an error and exit immediately when a local linked-node is configured

When a linked-node (in echocfg->Linked Nodes) contains one of the local system's FTN addresses, display/log an error and exit immediately, e.g.:
Configuration ERROR: Linked node #20 is your own address: 1:103/705

I'd perform this check in EchoCfg, but:
1. echocfg doesn't read the BBS's configuration files (where the local FTN addresses are configured), and
2. some sysops just directly edit their sbbsecho.ini file

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

https://gitlab.synchro.net/main/sbbs/-/commit/e10b39d1aee183a16a3d9458
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Generate a MSGID kludge for netmail messages created by SBBSecho

The "serialno" field is a bad/naive one (a time_t value), but this is really just an experiment for Ragnarok to see if this fixes issue #306 (with hotdoged receiving AreaFix responses/notices).

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

https://gitlab.synchro.net/main/sbbs/-/commit/27dfa4f6b9ebc59e1c4f097e
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Resolve gcc warning

warning: format ‘%lx’ expects argument of type ‘long unsigned int’

---
ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/55962a410034e3633fe3ff09
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Disable libarchive support for creating/appending bundles

libarchive apparently cannot be used for in-place modification of (e.g. adding files to) existing archives, so if a bundle already exists, this code would over-write it with a new archive containing just the latest packet. Issue reported by acn (IMZADI) via DOVE-Net.

I could and might create an update_archive() function which extracts and re-creates an archive with additional files, but since I don't have that yet, just disable this for now and always use an external archive utility to create or update bundles (so again, an "Archive" configuration is required in your sbbsecho.ini file, which you most likely already have).

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

https://gitlab.synchro.net/main/sbbs/-/commit/4ec5647c783a5f5af9d68611
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Resolve some Coverity-discovered issues

with lseek() argument types, ftell() return type, etc.

Likely none of these would be actual issues with files < 2GiB in size.

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

https://gitlab.synchro.net/main/sbbs/-/commit/f9a681ac286284fe57f7f5c2
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix possible negative offset to fseeko()

CID 350353

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

https://gitlab.synchro.net/main/sbbs/-/commit/c4b6a79d6f3a6b217cb87a1b
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Add subject.can (Subject filter file) support

For Trikester (DOVEMOD/BSMNTQQ)

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

https://gitlab.synchro.net/main/sbbs/-/commit/e530a12cf6268ef9ab47f36c
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix CID 174355: Big parameter passed by value

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

https://gitlab.synchro.net/main/sbbs/-/commit/726223ee8d8a7dde927fc833
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
For sub-boards configured to export "ASCII Only", convert UTF-8 correctly

This converts the body text as well as the to, from, and subject header
fields (first to CP437, then to ASCII).

This should address the issue raised in issue #386 with exporting UTF-8 sequences to some message networks.

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

https://gitlab.synchro.net/main/sbbs/-/commit/bf3da76e32fbc8cd7785fa1f
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Resolve GCC warnings

Fixes isue #388 - no change in behavior

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

On 4/3/22 16:51, Rob Swindell wrote:

https://gitlab.synchro.net/main/sbbs/-/commit/726223ee8d8a7dde927fc833 Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
For sub-boards configured to export "ASCII Only", convert UTF-8 correctly

This converts the body text as well as the to, from, and subject header fields (first to CP437, then to ASCII).

This should address the issue raised in issue #386 with exporting UTF-8 sequences to some message networks.

Maybe adding a "CP437/DOS Only" option? Not sure what the underlying
value is though.
--
Michael J. Ryan - tracker1@roughneckbbs.com
---
ï¿­ Synchronet ï¿­ Roughneck BBS - roughneckbbs.com

https://gitlab.synchro.net/main/sbbs/-/commit/414d34ec8bc2c13601ce476a
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix packet filename in "Gruned message" log entry on Win32

e.g. "Grunged message (type 2) from 4:80/1 at offset 58 in packet: (null)"

off_t is 64-bit, but long in 32-bit (on Win32), so needs a typecast here in lprintf() call (otherwise, the upper 4 bytes of the offset are interpreted
as the string address for the corresponding '%s' argument, the filename).

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

https://gitlab.synchro.net/main/sbbs/-/commit/2962e4a5bf733e4b0c3869c4
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix segfault when printing Bad-echo name after failing to load cfg

This is a weird one: sbbsecho ran right as I was saving msgs.cnf via
SCFG and it seems like it loaded 0-byte msgs.cnf into memory and this
segfault was a result of trying to print sub[INVALID_SUB]->code.

The use of [f]nopen() with proper share perms should have prevented this (truncated msgs.cnf read) from happening, so there's something else afoot here.

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

https://gitlab.synchro.net/main/sbbs/-/commit/0f0a8a1ae72c424509eaa72d
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Refactor the function: unpack_bundle()

1. When a 0-length bundle file was encountered or an unpacking error occurred,
any remaining bundles for the current search day-of-week (e.g. *.SU*) would
be skipped/ignored. This bug (issue #764, regarding the 0-length file part),
is fixed by not incrementing the day-of-week index in the main loop, but
rather only incremeting the index when all bundles for the current
day-of-week have been processed.
2. The age calculation for 0-byte/length bundle files was incorrect, so all
0-length bundle files would always be considered "less than 24-hours old"
(and thus, never auto-deleted).
This exacerbated the problem of issue #764 since it would persist until the
0-length files were manually deleted. Fixed the file age calculation and
now logging the date/timestamp of the 0-length file as well.
3. Don't do the switch/case/sprintf dance when we're not re-running a glob()
search.
4. Replace the switch/case statement with an array of week day names/patterns. 5. Ignore (with a warning log message) any sub-directories of the inbound
directory that happen to match the bundle file search pattern.
6. Use better variable naming.
7. Refer to files with a length of 0 as "0-length" instead of "0-byte" in log
messages.

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

https://gitlab.synchro.net/main/sbbs/-/commit/6177a1c02241acc45a1b0858
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix potential null pointer dereference

strListReadFile() can return NULL upon error

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

https://gitlab.synchro.net/main/sbbs/-/commit/c0305b87e10ec27852fe13f1
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Log messages when (attempting) to notify mail recipients (via short messages)

ERROR-level messages with error number, upon failure and debug-level message upon success.

To hopefully help Deon get to the bottom of his SBBSecho echomail notification issue.

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

Re: src/sbbs3/sbbsecho.c
By: Rob Swindell (on Debian Linux) to Git commit to main/sbbs/master on Sun Jan 19 2025 02:56 am

Howdy,

Log messages when (attempting) to notify mail recipients (via short messages)

To hopefully help Deon get to the bottom of his SBBSecho echomail notification issue.

Thanks, I've kicked of a build and will try this tomorrow. Thanks :)


...ëîåï

---
þ Synchronet þ AnsiTEX bringing back videotex but with ANSI

https://gitlab.synchro.net/main/sbbs/-/commit/4bad3a54de5334550d9f5466
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
More log messages around notifying users of imported echomail, for Deon

Log levels ERROR, NOTICE, and DEBUG

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

https://gitlab.synchro.net/main/sbbs/-/commit/ff1ebae7920c50df2855051c
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Add debug-level log messages when import_netmail() returns a non-zero value

To help debug any situations where import_netmail() might silently fail
(though I don't anticipate there are any, Accession suggested there was).

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

Why are these being posted? Curious

--- Steve K9ZW via SPOT BBS

--- Mystic BBS v1.12 A49 2024/05/29 (Raspberry Pi/32)
* Origin: SPOT BBS / k9zw (1:154/154)
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: Re: src/sbbs3/sbbsecho.c
By: k9zw to Rob Swindell (on Windows 11) on Tue Feb 04 2025 06:54 am

Why are these being posted? Curious

This is the "Synchronet Programming (C/C++ and Git)" Conference, so the source code repository activity (changes to the Synchronet source, primarily) get posted here, so sysop can see what's changing (fixes, new features, etc.).
--
digital man (rob)

This Is Spinal Tap quote #5:
Nigel Tufnel: Authorities said... best leave it... unsolved.
Norco, CA WX: 55.6øF, 78.0% humidity, 0 mph ENE wind, 0.00 inches rain/24hrs ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

On 04 Feb 2025, Digital Man said the following...

Re: Re: src/sbbs3/sbbsecho.c
By: k9zw to Rob Swindell (on Windows 11) on Tue Feb 04 2025 06:54 am

Why are these being posted? Curious

This is the "Synchronet Programming (C/C++ and Git)" Conference, so the source code repository activity (changes to the Synchronet source,

Alas my system merged this in another echo... puzzling how at the moment...

appreciate the reply!

--- Steve K9ZW via SPOT BBS

--- Mystic BBS v1.12 A49 2024/05/29 (Raspberry Pi/32)
* Origin: SPOT BBS / k9zw (1:154/154)
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: Re: src/sbbs3/sbbsecho.c
By: k9zw to Digital Man on Tue Feb 04 2025 05:48 pm

source code repository activity (changes to the Synchronet source,

Alas my system merged this in another echo... puzzling how at the moment...

appreciate the reply!

put your data files in their own sub directory for each msg network you have. ---
þ Synchronet þ ::: BBSES.info - free BBS services :::

MRO wrote to k9zw <=-

source code repository activity (changes to the Synchronet source,

Alas my system merged this in another echo... puzzling how at the moment... appreciate the reply!

put your data files in their own sub directory for each msg network you have.

That isn't necessary and certainly is not the default way.



... He does the work of 3 Men...Moe, Larry & Curly
--- MultiMail/Linux v0.52
þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL

Re: Re: src/sbbs3/sbbsecho.c
By: MRO to k9zw on Tue Feb 04 2025 06:04 pm

Alas my system merged this in another echo... puzzling how at the moment...

appreciate the reply!

put your data files in their own sub directory for each msg network you have.

I think it may be the internal sub-board code that matters, not really where the files are stored. The internal sub-board codes need to be unique. If 2 sub-boards share the same internal code, then I'm sure that would cause messages to get duplicated in both sub-boards. But it also doesn't hurt to have the files in separate directories.

Nightfox

---
þ Synchronet þ Digital Distortion: digitaldistortionbbs.com

Re: Re: src/sbbs3/sbbsecho.c
By: Nightfox to MRO on Tue Feb 04 2025 05:28 pm

Re: Re: src/sbbs3/sbbsecho.c
By: MRO to k9zw on Tue Feb 04 2025 06:04 pm

Alas my system merged this in another echo... puzzling how at the moment...

appreciate the reply!

put your data files in their own sub directory for each msg network you have.

I think it may be the internal sub-board code that matters, not really where the files are stored. The internal sub-board codes need to be unique. If 2 sub-boards share the same internal code, then I'm sure that would cause messages to get duplicated in both sub-boards. But it also doesn't hurt to have the files in separate directories.

In this case, the system with the issue is not a Synchronet system, so I don't know if "internal codes" apply. :-)
--
digital man (rob)

Steven Wright quote #7:
A clear conscience is usually the sign of a bad memory.
Norco, CA WX: 54.0øF, 78.0% humidity, 3 mph WNW wind, 0.00 inches rain/24hrs ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: Re: src/sbbs3/sbbsecho.c
By: Digital Man to Nightfox on Tue Feb 04 2025 08:00 pm

In this case, the system with the issue is not a Synchronet system, so I don't know if "internal codes" apply. :-)

Ah, I didn't see (or notice) it's not a Synchronet system. :)

Nightfox

---
þ Synchronet þ Digital Distortion: digitaldistortionbbs.com

https://gitlab.synchro.net/main/sbbs/-/commit/3ff043da84462d6cf5db9a64
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Log warning-level message when we can't auto-add a sub

... because there's no linked-node configured as the uplink for the parent message group.

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

https://gitlab.synchro.net/main/sbbs/-/commit/d652854faa37cb4cdf507938
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Address some MSVC static analysis warnings

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

https://gitlab.synchro.net/main/sbbs/-/commit/fabef9ea90ed2758081eec2a
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Only log one warning per invocation about inability to auto-add sub

Just the first sub that couldn't be auto-added.

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

https://gitlab.synchro.net/main/sbbs/-/commit/8010070c0bc86aaf8104a144
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Take the configured origin line chars into account when determining charset

and if the message is UTF-8, encode the origin line as UTF-8 too.
If the message is straight ASCII (e.g. the sub-board is configured as ASCII only), convert the configured origin line to ASCII, before appending.

At this time, only ASCII and CP437 encodings of originlines are supported
in Synchronet (imported and exported origin lines can contain UTF-8).

This should address the issue raise by Sergey Dorofeev (2:5020/12000) in the FidoNet UTF-8 echo whereby messages exported from Synchronet systems (presumably using SBBSecho) could contain a mixture of CP437 and UTF-8 encodings (!) when the sysop had CP437 chars in their configured origin line.

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

https://gitlab.synchro.net/main/sbbs/-/commit/ca0d64e4e73f352dbfcd4f1b
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Eliminate some unnecessary typecasts and parens

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

https://gitlab.synchro.net/main/sbbs/-/commit/f78d5395969b6a38a4db8adc
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Add typecast to elminate GCC warning

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