https://gitlab.synchro.net/main/sbbs/-/commit/ca0765f3dd2305342f23d6b5
Modified Files:
src/sbbs3/zmodem.c zmodem.h
Log Message:
zmodem: fix windowed transfers hanging at 2 GiB (GitLab #1196)

The ZMODEM transmit-window / ACK file positions were held in signed
int32_t (ack_file_pos, crc_request, and the pos parameters of zmodem_send_pos_header / zmodem_send_ack). Once a file offset crossed
2^31, these went negative, so the sender's window arithmetic (current_window_size = current_file_pos - ack_file_pos) computed a bogus
~4 GiB window that permanently exceeded any configured max window; the
sender then throttled forever waiting for a ZACK it could never accept,
and the transfer stalled the instant it passed 2 GiB. The ZACK range
check in zmodem_handle_zack (which already takes uint32_t) likewise
rejected valid acknowledgements above 2 GiB.

Widen those positions to uint32_t, matching rxd_header_pos, which is
already unsigned and correct through the protocol's 4 GiB wire limit.
The byte-packing in zmodem_send_pos_header is unchanged (it masks each
byte), so the on-wire encoding is identical; only the local arithmetic
and comparisons are corrected. The receive/data path was already
64-bit-clean (int64_t offsets, fseeko/ftello), so this is purely the
window/ACK accounting.

Positions >= 4 GiB remain limited by the 32-bit ZMODEM header position
field, which is inherent to the protocol and out of scope here.

This code is shared with SyncTERM, so its windowed uploads past 2 GiB
are fixed by the same change.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)