Subj : docs/v322_new.md src/sbbs3/sexyz.c
To   : Git commit to main/sbbs/master
From : Rob Swindell (on Debian Linux)
Date : Tue Aug 25 2026 01:12:30

https://gitlab.synchro.net/main/sbbs/-/commit/222dbfc7f6fd9921e2754adc
Modified Files:
	docs/v322_new.md src/sbbs3/sexyz.c
Log Message:
sexyz: expose the ZMODEM file-management option, and -e for ESCCTL

The engine has carried management_protect / management_clobber /
management_newer for years and honors all three in zmodem_send_zfile(),
but nothing ever set them -- not sexyz, not SyncTERM -- so every send
fell through to the default and announced ZF1_ZMCRC ("transfer if
different CRC or length").  The protocol work was already done; only
the plumbing was missing.

Add SendManagement to sexyz.ini's [ZMODEM] section, taking crc (the
default, unchanged), clobber, protect or newer.  One enumerated key
rather than three booleans, because the engine treats them as mutually
exclusive in a fixed precedence and three independent flags could be
set to a combination that silently resolves to one of them.

On the command line, -p and -n are new and match lsz.  -y keeps its
current meaning when receiving -- may we overwrite a file already here
-- and gains the matching one when sending: tell the receiver to
overwrite its own.  That is exactly the lrzsz split, where lsz -y sets
ZMCLOB and lrz -y clobbers locally, and -y was previously documented as
applying only to receives, so nothing that worked before changes.  Note
the two act on different disks: receiving, the destination is this
machine; sending, it is the user's.  Synchronet's own receiver ignores
a ZFILE's management field entirely, so this reaches third-party
terminals only.

Also add -e, the command-line equivalent of the existing
EscapeCtrlChars ini key, for links that do not pass control characters
intact.  Verified against lrzsz: receiving with -e, the wire grows from
4,312,067 to 5,245,286 bytes for the same 4 MB file, within 0.005 % of
what lrz -e negotiates from the same sender, and verifies
byte-identical.  It took the hex-header terminator fix in the preceding
commit to work at all.

When sending, -e is subject to the receiver's ZRINIT, which is what the
engine derives escape_ctrl_chars from, so the usage text says the
receiver's request governs rather than promising something the protocol
layer overrides.  Sending with ESCCTL actually negotiated is broken for
a separate, pre-existing reason noted in the preceding commit.

Options parse after the ini is read, so a flag overrides the file;
verified with SendManagement=protect in the ini and -y on the command
line yielding "overwriting destination".
--- SBBSecho 3.37-Linux
 * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

.