src/sbbs3 sbbsecho.c 3.142 3.143
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv27640

Modified Files:
sbbsecho.c
Log Message:
When exporting NetMail from data/mail.* to netmail/*.msg, map the SMB
aux/net attributes to FidoNet msg header attributes:
- CRASH
- FILEREQUEST (FREQ)
- RECEIPTREQ (RRREQ)

This should fix the FREQ netmail issue reported by Richard Williamson (RICHARDF). Thanks for the bug report!



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

src/sbbs3 sbbsecho.c 3.143 3.144
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv15382

Modified Files:
sbbsecho.c
Log Message:
Attempt to re-create outbound directories in mutex (.bsy) file lock loop, just in case something (e.g. Argus mailer) deleted it while we were waiting our
turn to use it. As reported by Alterego (ALTERANT)



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

src/sbbs3 sbbsecho.c 3.144 3.145
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv398

Modified Files:
sbbsecho.c
Log Message:
More loop prevention: check a message's PATH in addition-to its SEEN-BYs in write_to_pkts():
If for some weird reason a downlink's address is in the PATH, but not in the SEEN-BYs, detect as a loop and don't send to (add to an outbound pkt for) the downlink.

This is an experimental change to see if it addresses the issue reported by Richard Williamson and Mark Lewis with regards to dupes in the COOKING
echo from point nodes off 1:396/45.


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

src/sbbs3 sbbsecho.c 3.145 3.146
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv3751

Modified Files:
sbbsecho.c
Log Message:
Even more loop-prevention paranoia:
If a packed messages contains no PATH or SEEN-BY lines, we can still detect
and prevent a message loop by comparing the origin address in the packet header against the downlink's address and if it's a match, skip that downlink.
It is still possible that a packed message header contains a different origin address than the packet header, and we're actually over-writing the packed messge header variable with the parsed Origin: line address (if there is one), so perhaps we'll want to compare the (actual) packed message header origin address too at some point in the future, if loops continue to be a problem.



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

src/sbbs3 sbbsecho.c 3.146 3.147
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv19001

Modified Files:
sbbsecho.c
Log Message:
Enhancement for Alterego (ALTERANT):
Don't ever route netmail when the destination zone/net/node matches a local
AKA (ignoring the point value).



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

Re: src/sbbs3/sbbsecho.c
By: rswindell to CVS commit on Sun Nov 17 2019 04:31 pm

Don't ever route netmail when the destination zone/net/node matches a local AKA (ignoring the point value).

Actually, what will happen to it?

I'm assuming if the point is defined in sbbsecho.ini, it will be packed for the downstream point.

But what will happen otherwise? Perhaps it could be re-addressed to the sysop of the AKA, so that they are aware?
...ëîå*

... When two Englishmen meet their first talk is of the weather.

---
þ Synchronet þ Alterant | an SBBS in Docker on Pi!

Re: src/sbbs3/sbbsecho.c
By: Alterego to Digital Man on Mon Nov 18 2019 12:27 pm

Re: src/sbbs3/sbbsecho.c
By: rswindell to CVS commit on Sun Nov 17 2019 04:31 pm

Don't ever route netmail when the destination zone/net/node matches a local AKA (ignoring the point value).

Actually, what will happen to it?

Normal processing, just not routed.

I'm assuming if the point is defined in sbbsecho.ini, it will be packed for the downstream point.

Yup.

But what will happen otherwise? Perhaps it could be re-addressed to the sysop of the AKA, so that they are aware?

I don't follow.

digital man

This Is Spinal Tap quote #44:
It really, it does disturb me, but i'll rise above it; I'm a professional. Norco, CA WX: 75.1øF, 18.0% humidity, 0 mph WSW wind, 0.00 inches rain/24hrs

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

Re: src/sbbs3/sbbsecho.c
By: Digital Man to Alterego on Sun Nov 17 2019 07:02 pm

But what will happen otherwise? Perhaps it could be re-addressed to
the sysop of the AKA, so that they are aware?

I don't follow.

What will happen to the incoming netmail where the point doesnt exist.

IE: Somebody sends a netmail to 1:2/3.4 - and .4 is not configured in sbbsecho.ini, will:
* The netmail still packed up into the outbound for when a .4 does eventually connect, or
* The netmail will be discard
* The packet will be renamed ".bad"...

?

I'm wanting to know what will happen to the netmail and how will the sysop of 1:2/3 know about an incoming netmail destined for a point that has not been configured.
...ëîå*

... I think sex is better than logic, but I can't prove it.

---
þ Synchronet þ Alterant | an SBBS in Docker on Pi!

Re: src/sbbs3/sbbsecho.c
By: Alterego to Digital Man on Mon Nov 18 2019 02:17 pm

Re: src/sbbs3/sbbsecho.c
By: Digital Man to Alterego on Sun Nov 17 2019 07:02 pm

But what will happen otherwise? Perhaps it could be re-addressed to
the sysop of the AKA, so that they are aware?

I don't follow.

What will happen to the incoming netmail where the point doesnt exist.

IE: Somebody sends a netmail to 1:2/3.4 - and .4 is not configured in sbbsecho.ini, will:
* The netmail still packed up into the outbound for when a .4 does eventually connect, or
* The netmail will be discard
* The packet will be renamed ".bad"...

?

I'm wanting to know what will happen to the netmail and how will the sysop of 1:2/3 know about an incoming netmail destined for a point that has not been configured.

The change I made was in pack_netmail(), so the netmail message would still be packed for the destination node, just as if there was no "route" entry matching its address. If the ".4" node ever does connect, it should get the packet with the netmail inside.

digital man

Synchronet "Real Fact" #83:
Donations to the Synchronet project are welcome @ http://wiki.synchro.net/donate
Norco, CA WX: 70.3øF, 21.0% humidity, 0 mph SW wind, 0.00 inches rain/24hrs

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

src/sbbs3 sbbsecho.c 3.147 3.148
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/home/rswindell/sbbs/src/sbbs3

Modified Files:
sbbsecho.c
Log Message:
Update to previous commit: always read/use the destination node config,
(e.g. for Hold status) even if/when it's a point off of us.



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

src/sbbs3 sbbsecho.c 3.149 3.150
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/home/rswindell/sbbs/src/sbbs3

Modified Files:
sbbsecho.c
Log Message:
Log any error reading message header when exporting NetMail (from SMB to *.msg).



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

src/sbbs3 sbbsecho.c 3.150 3.151
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/home/rswindell/sbbs/src/sbbs3

Modified Files:
sbbsecho.c
Log Message:
Fix bug introduced in rev 1.236 (April-3-2014):
Areafix requests to unlink a node from an area would corrupt the list of
linked nodes: the *last* listed node would always be removed. If this was
not the node that submitted the areafix request, then 2 nodes would be
removed from the list of linked-nodes for an echo.
To simplify this, we're just going to not write the removed node back to
the area file, but leave it in the in-memory list. So technically, the node won't be unlinked until the next run of SBBSecho when the area file is re-parsed. If that's a problem, we can always add run-time removal from
the in-memory list later. Reported by Alterego (ALTERANT).



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

src/sbbs3 sbbsecho.c 3.151 3.152
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv1945

Modified Files:
sbbsecho.c
Log Message:
Move debug log message ("NOT EXPORTING previously-rescanned message from: <addr>")
to before the actual export, so that if an area has no downlinks, you won't actually see this errorneous but harmless log message. Also include the "export-to" address in the message.



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

src/sbbs3 sbbsecho.c 3.152 3.153
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv25668

Modified Files:
sbbsecho.c
Log Message:
Include the echo Title (from an echolist), if found, in the echostats.ini.
This makes this file more suitable for import into SCFG->Message Areas (something I'll work on soon), i.e. as an alternative to importing badareas.lst


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

src/sbbs3 sbbsecho.c 3.153 3.154
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv5966

Modified Files:
sbbsecho.c
Log Message:
When writing badareas.lst, don't space-pad the areatags needlessly:
calculate the longest tag first, then use that value for the padding.



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

src/sbbs3 sbbsecho.c 3.154 3.155
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv9012

Modified Files:
sbbsecho.c
Log Message:
Reduce unnecessary padding of AreaTags in AreaFix responses.


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

src/sbbs3 sbbsecho.c 3.156 3.157
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv29346

Modified Files:
sbbsecho.c
Log Message:
Added some debug and error level log output to help Angel Ripoll figure out
why his messages aren't being exported to packets.
Don't increment the per-area-export counter when write_to_pkts() returns false.


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

src/sbbs3 sbbsecho.c 3.157 3.158
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv27213

Modified Files:
sbbsecho.c
Log Message:
Modify a single log message, the new "Added <area> message from x to packets": Track and log the packet-export exceptions (link packets that were *not* exported-to) and detail those exceptions (number of seen-bys, paths, origin address, etc.) which were triggered.
This requires latest xpdev/str_list.*


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

src/sbbs3 sbbsecho.c 3.158 3.159
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv27706

Modified Files:
sbbsecho.c
Log Message:
Make use of strListIsEmpty() - optimization.


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

src/sbbs3 sbbsecho.c 3.159 3.160
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv6003

Modified Files:
sbbsecho.c
Log Message:
Remove attributes CRASH, HOLD, and LOCAL from the headers of netmail messages be unpacked into stored messages (.msg). Debug-level log message indicating that one or more attributes were removed (and which ones, in hex).
This set of stripped attribute flags could easily be configurable, if that turns out to be desirable.


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

src/sbbs3 sbbsecho.c 3.160 3.161
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv31899

Modified Files:
sbbsecho.c
Log Message:
Fix bug reported by Mark Lewis (Rampage@SESTAR), when packing NetMail messages (from stored messages in .msg files into packets), the origin net/node within the *packed message* header would be set to the local system's address net/node (for the destination zone), always. This is the appropriate action when packing EchoMail, but not for NetMail.

Now, there are lot of other header fields in the packed message that contain the source/origin address (e.g. @FMPT, @INTL kludges) and those would reflect the original origin address still. And these fields take precedence over the orign net/node fields of the packed message header. So I'm not sure this bug would actually cause any problems anywhere, but it was a bug all the same.


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

src/sbbs3 sbbsecho.c 3.162 3.163
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/home/rswindell/sbbs/src/sbbs3

Modified Files:
sbbsecho.c
Log Message:
Fix bug in previous commit, 0-initialize the usernumber so that messages imported for robots actually have a 'to' index value of 0.



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

src/sbbs3 sbbsecho.c 3.164 3.165
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/home/rswindell/sbbs/src/sbbs3

Modified Files:
sbbsecho.c
Log Message:
An extra debug-level log message when exporting a netmail from SMB.
Don't add another tear-line (---) if one already exists, when creating
netmail (.msg) stored messages.



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

src/sbbs3 sbbsecho.c 3.165 3.166
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv29169

Modified Files:
sbbsecho.c
Log Message:
MKDIR -> mkpath


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

src/sbbs3 sbbsecho.c 3.166 3.167
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv1773

Modified Files:
sbbsecho.c
Log Message:
When exporting netmail from SMB->.msg, always set the "SENT" net-attribute
and clear the "IN-TRANSIT" net-attribute of the original message, even if we're flagging it for deletion (the delete attribute could always be toggled off).


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

src/sbbs3 sbbsecho.c 3.167 3.168
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv28557

Modified Files:
sbbsecho.c
Log Message:
When import netmail for robots, don't perform duplicate message body-text checking.


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

src/sbbs3 sbbsecho.c 3.168 3.169
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv11388

Modified Files:
sbbsecho.c
Log Message:
When importing messages into a local msgbase that contained an origin line
but no tear line, I noticed that the initial space before "* Origin" was absent from the tail. It turns out the missing space character was being appended to the end of the body text. While investigating why that was, I was dismayed at the cruftiness of code but totally suprised that there was 80-column word-wrap logic in here (!). Removed that word-wrap logic <blush> and fixed the origin thing. More clean-up coming up next.


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

src/sbbs3 sbbsecho.c 3.169 3.170
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv20270

Modified Files:
sbbsecho.c
Log Message:
Remove unnecessary typecasts.


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

Re: src/sbbs3/sbbsecho.c
By: rswindell to CVS commit on Wed Apr 29 2020 21:34:37

Modified Files:
sbbsecho.c
Log Message:
When importing messages into a local msgbase that contained an origin
line but no tear line, I noticed that the initial space before
"* Origin" was absent from the tail. It turns out the missing space character was being appended to the end of the body text. While investigating why that was, I was dismayed at the cruftiness of code
but totally suprised that there was 80-column word-wrap logic in here
(!). Removed that word-wrap logic <blush> and fixed the origin thing.
More clean-up coming up next.

i'm glad you found this! i had thought to go rummaging through the code looking to see if there was such in place but the TODO list is quite long... i've been noticing a difference in the formatting of posts when compared to how they arrive via QWK and when they're gated to FTN... i'm curious to see if they're now more similar or exact to the QWK arrivals when seen on the FTN side... they should be, now, with this forced 80 column formatting removed :)


)\/(ark

---
þ Synchronet þ The SouthEast Star Mail HUB - SESTAR

Re: src/sbbs3/sbbsecho.c
By: Rampage to digital man on Thu Apr 30 2020 07:56 am

Re: src/sbbs3/sbbsecho.c
By: rswindell to CVS commit on Wed Apr 29 2020 21:34:37

Modified Files:
sbbsecho.c
Log Message:
When importing messages into a local msgbase that contained an origin line but no tear line, I noticed that the initial space before
"* Origin" was absent from the tail. It turns out the missing space character was being appended to the end of the body text. While investigating why that was, I was dismayed at the cruftiness of code
but totally suprised that there was 80-column word-wrap logic in here (!). Removed that word-wrap logic <blush> and fixed the origin thing. More clean-up coming up next.

i'm glad you found this!

If someone had asked, I would have said that SBBSecho did not do that.

i had thought to go rummaging through the code
looking to see if there was such in place but the TODO list is quite long... i've been noticing a difference in the formatting of posts when compared to how they arrive via QWK and when they're gated to FTN... i'm curious to see if they're now more similar or exact to the QWK arrivals when seen on the FTN side... they should be, now, with this forced 80 column formatting removed :)

Cool, let me know what you find.

digital man

Synchronet "Real Fact" #45:
Synchronet External "Plain Old Telephone System" support was introduced in 2007.
Norco, CA WX: 73.9øF, 69.0% humidity, 0 mph SSE wind, 0.00 inches rain/24hrs

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

src/sbbs3 sbbsecho.c 3.170 3.171
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv14414

Modified Files:
sbbsecho.c
Log Message:
Always delete exported netmail if there's no SENDEREXT (from_ext) as this could result in orphaned sent-mail otherwise.


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

src/sbbs3 sbbsecho.c 3.171 3.172
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv23694

Modified Files:
sbbsecho.c
Log Message:
Resolve weird Clang warning: format specifies type 'unsigned short' but the argument has type 'int'

So a (ushort&ushort) == int? That makes no sense.When in doubt, typecast!


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

src/sbbs3 sbbsecho.c 3.173 3.174
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv22900

Modified Files:
sbbsecho.c
Log Message:
If an export netmail message has MSGID/REPLY header fields, add those as kludges (needed for including message-IDs in exported netmail).


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

src/sbbs3 sbbsecho.c 3.174 3.175
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv1776

Modified Files:
sbbsecho.c
Log Message:
Extra log level message (INFO, WARNING, and DEBUG) when moving netamil file attachments (attached files) - for debugging the issue reported by
alterego (ALTERANT)


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

src/sbbs3 sbbsecho.c 3.175 3.176
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv10832

Modified Files:
sbbsecho.c
Log Message:
import_netmail(): Safer string handline and a bit more/consistent log output around attached file handling (especially if mv() fails).


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

https://gitlab.synchro.net/sbbs/sbbs/-/commit/57afc83c4a58a1a7f6af05ee
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Signal the sub-board's configured semaphore file when importing echomail

At the request of alterego (ALTERANT), if a sub-board has a "post semaphore" configured, signal (touch) it whenever a message is imported via SBBSecho into that sub-board.

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

https://gitlab.synchro.net/sbbs/sbbs/-/commit/ddba8d7cec9cd0367d7e0480
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix previous commit: we need to use mycmdstr(), not cmdstr().

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

https://gitlab.synchro.net/sbbs/sbbs/-/commit/da486a78c63293a86718c78d
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Don't attempt to parse origin addr from origin lines in NetMail msgs

Apparently, some versions or configurations of Mystic BBS will include an Origin Line in FTN NetMail messages. That would've been okay for SBBSecho, except these origin lines do not contain an FTN address (in parenthesis).

So, firstly: when importing NetMail messages (subnum=INVALID_SUB), don't attempt to parse any Origin Lines. Secondly, fix up the Origin Line parse
code a bit better detect the case when no FTN address is actually present.

---
þ 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