12-Nov-97 16:05:51-GMT,2036;000000000001 Return-Path: Received: (from fdc@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id LAA10751; Wed, 12 Nov 1997 11:05:46 -0500 (EST) Date: Wed, 12 Nov 97 11:05:46 EST From: Frank da Cruz To: Joe Doupnik Subject: Re: MSK 3.15-1, /recursive In-Reply-To: Your message of Tue, 11 Nov 1997 11:48:00 -0600 (MDT) Message-ID: > I do have get /recur tacked in and will do some quick checks > this morning on it. It turns out to be simple to implement in MSK. > What is not so simple is the eventual pushing down of operating > characteristics (binary/text etc) on a per transfer basis, making a total > of three sets: default/fixed modes, per xfer modes, negotiated modes, not > to mention per-packet modes to get the protocol started. Oh well. > Right, it's getting pretty complicated. The current rules in C-K are (using fictitious variable names): BINARY is the global transfer mode. When protocol mode is entered, BINARY is saved in G_BINARY ("global binary"). If the transfer mode is overridden automatically at Send/Init time by the WHOAMI mechanism, BINARY is replaced by the indicated mode as the prevailing mode for the rest of the transfer. When receiving files, for each file, the BINARY value is saved in P_BINARY, then switched to the value indicated in the A packet, and then BINARY is restored from P_BINARY at the end of the file. When sending files, for each file, the BINARY value is saved in P_BINARY, then switched according to whatever mechanism we use for recognizing local files to be text or binary (e.g. in VMS, the directory info, or in other C-Kermits, the patterns), and then BINARY is restored from P_BINARY at the end of the file. When leaving protocol mode (including on Ctrl-C interruption, E-packet, etc), we restore the BINARY value from G_BINARY. Wrinkles: If the server gets a REMOTE SET FILE TYPE command, it affects BINARY and G_BINARY. There are probably also a few more... - Frank