#46 Ymodem-g receive incorrect behavior

[Anonymous]

The Ymodem-g receive sequence is incorrect and causes failed transfers when receiving files from senders which strictly adhere to the Ymodem-g standard.

At the end of each file SyncTERM responds to the sender's EOT with a NAK, expecting the sender to transmit another EOT which is then acknowledged with a final ACK. While this is acceptable for Ymodem, the Ymodem-g standard expects the receiver to respond only with an ACK. From Chapter 6 of the Ymodem protocol reference:

"The sender expects an inital G to initiate the transmission of a
particular file, and also expects an ACK on the EOT sent at the end of
each file."

It is also demonstrated in the Ymodem-g transmission session example in the same chapter. Some senders (correctly) interpret this break in expected sequence as an error and will abort the transfer. SyncTERM should be responding with an ACK on the first EOT.

The X/Ymodem EOT->NAK->EOT->ACK kludge is to prevent transmission errors from mimicking a false EOT. When Ymodem-g is in use these errors should not be possible to create. Using the kludge in Ymodem-g mode isn't necessary and ends up violating the standard.

[Rob Swindell]

Interestingly, this is how the sexyz/SyncTERM Ymodem-G implementation worked back in 2005 but was inexplicitly changed:
http://cvs.synchro.net/cgi-bin/viewcvs.cgi/src/sbbs3/xmodem.c?r1=1.15&r2=1.16

[Rob Swindell]

Fixed: http://cvs.synchro.net/gitpushlog.ssjs#b92bf999e3800568eb4b3e3bbebab87b2443ef51

[Anonymous]

Thank you for addressing and fixing this.