NetworkNews

C-Kermit 11: test the transfer policy before migrating

On this page
  1. New release, different defaults
  2. A migration matrix for an existing job
  3. Make compatibility an explicit decision

A file-transfer upgrade is successful when the intended file arrives intact and failures are visible. Merely connecting to the remote system is not enough.

Conceptual file collision example with existing payload A and incoming payload B. BACKUP preserves the old content under a backup name while accepting B; REJECT keeps A and refuses B. Illustration of policy, not an executed transfer.
Conceptual file collision example with existing payload A and incoming payload B. BACKUP preserves the old content under a backup name while accepting B; REJECT keeps A and refuses B. Illustration of policy, not an executed transfer. Chart : PeopleAreGeek. Data source.
View full-size image

New release, different defaults

C-Kermit 11.0.506, released August 3, is the first non-beta since 2011. It adds IPv6 and changes collision handling to REJECT and transfer mode to MANUAL. Confirmation for unsolicited files excludes headless server/iksd operation. Legacy compatibility modes restore older settings but weaken protections.

By September 8, 11.0.509 is available, with fixes including terminal-resize forwarding, PTY cleanup and possible Telnet stalls. Read the maintenance notes as well as the major-release announcement when selecting a package.

A migration matrix for an existing job

Use a disposable destination and a copy of a representative transfer, not the only copy of production data. Record the old job’s explicit configuration before changing anything. The following are proposed checks, not transfers performed by PeopleAreGeek.

CaseEvidence to retain
Destination file absentIntended pathname, received size and payload comparison
Same filename already presentWhether the job rejects, replaces or preserves it, and how that outcome is reported
Binary payload and a text payloadByte integrity for binary; deliberately expected line-ending conversion for text
Interrupted connectionVisible failure, handling of partial data and a deliberate retry policy
Scheduled unattended runBehaviour without a person available to answer prompts

The cover illustrates the second row: identical incoming data can produce different destination outcomes under different collision policies. That is why “the server accepted the connection” is not a sufficient success criterion.

Make compatibility an explicit decision

Do not enable a broad legacy mode solely because a script is old. First identify which setting it actually depends on. If a temporary compatibility mode is necessary, document its scope and keep the trial separate from routine transfers until the outcome is checked.

The practical target is a job that states its transfer type, destination policy and failure behaviour deliberately. That makes the next upgrade easier to assess too: compare the contract of the job with the new release, rather than hope inherited defaults remain unchanged.

September 8: verify changed defaults and headless exception, add 11.0.509 maintenance, replace blanket legacy-mode advice with a transfer validation matrix.