Subj : src/sbbs3/zmodem.c To : Git commit to main/sbbs/master From : Rob Swindell (on Debian Linux) Date : Mon Aug 24 2026 20:32:03 https://gitlab.synchro.net/main/sbbs/-/commit/decf9d9ef8da1209bf890cee Modified Files: src/sbbs3/zmodem.c Log Message: zmodem: don't abort a receive after the tenth error of the whole file zmodem_recv_file_data() counted errors in a local that was set to zero once per file and only ever incremented, so the tenth error ended the transfer however far apart those errors were and however cleanly each had been recovered. A receive over any link with a non-zero error rate therefore had a file size beyond which it could not succeed, while the sender in the same conditions ran indefinitely: zmodem_send_from() counts consecutive_errors and clears it on success. Reset the count whenever the file position has advanced past the position the last error was recorded at, which is the receive-side statement of the same rule. A run of errors with no progress between them still stops at max_errors, so a wedged transfer ends as before. Measured with the bench harness injecting bit errors at 3e-6 per byte into an 8 MB transfer -- around 25 corrupted subpackets, each individually recovered. Before, the receiver aborted at the tenth every time; after, all three runs complete and verify, with the error counter returning to zero between them. zmtx/zmrx survives the same treatment and lrzsz usually does, which is what prompted looking at this. Co-Authored-By: Claude Opus 5 (1M context) --- SBBSecho 3.37-Linux * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705) .