https://gitlab.synchro.net/main/sbbs/-/commit/fe2d6930583d7961596c3e1c
Modified Files:
src/sbbs3/sbbsecho.c sbbsecho.h
Log Message:
Don't write empty PATH: control line to exported echomail message

Points don't normally have any addresses to add to the PATH: line, so
(as was pointed out in the FIDOTEST echo), an empty PATH: line would be included in exported echomail messages from points.

Although this isn't a violation of FTS-4, it is a violation of its proposed successor: FSC-74:

"Blank" path lines shall not be transmitted

And this caused a duplicate PATH: line to be added by FMail when processing such messages.

This change also eliminates possibility of adding "\r\x01PATH:" not
followed by space (ASCII 32) character, which was also a violation of FSC-74.

I resisted the urge to clean-up this crufty bit of code here and made this commit the minimal necessary change.

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

https://gitlab.synchro.net/main/sbbs/-/commit/ffcb56c0e13b5a147c109557
Modified Files:
src/sbbs3/sbbsecho.c sbbsecho.h
Log Message:
REQ files aren't supposed to be listed in flow files

Per FTS-5005:

4.1 File request files are named using the same method as flow
files, with an extension of req. The format of request files
is documented in FTS-0006. File requests have no flavour on
their own. They DO NOT initiate a poll to the remote system,
and must be accompanied by a [reduced] flow file.

I'm not sure why "reduced" is in brackets here (implying optional?) but apparently accompanying a .req file with a full/normal FLO entry causes duplicate requests/replies as reported recently by Dan (Gamgee @ PALANTIR).

Incremented version to 3.34.

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

https://gitlab.synchro.net/main/sbbs/-/commit/eebfd74ddc924e1e98c2b159
Modified Files:
src/sbbs3/sbbsecho.c sbbsecho.h
Log Message:
Unpack bundles starting from 6 weekdays ago, not (always) Sunday

There was a conversation in the SYNCHRONET echo/conference about message
import ordering and it occurred to me that SBBSecho shouldn't always start the bundle search/unpack with Sunday (*.SU?) as we might import bundles out of order if multiple bundles spanning multiple days came in at once (or were collected over time without running SBBSecho import). Of course, the whole
"day of week" naming scheme doesn't work very well if the link is in a different time zone, but this is no less accurate than just always starting the search from Sunday (*.SU*) and will usually be more "chronologically" accurate.

Using UTC to determine the current "day of week" for creating and consuming bundles would be more deterministic, but alas, it's not how things have been done (anyone have a document/reference for the origination of the defacto bundle naming scheme?).

FSC-23 refers to this scheme as "Day-of-week bullshit", and I have to agree. UTC Day of year would've been a much better chronological and sequential
naming scheme, but I think some systems were sensistive to the size of bundles and packets and needed them split-up and the DOS 8.3 filename limitation had
to be designed around.

One solution is to just always transfer packets and never bundles since packets are usually unambiguously and sequentially named (SBBSecho supports this just fine).

Increment version to 3.35

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