> To: cmg@watsun.cc.columbia.edu > From: Paul W Placeway > Subject: Tagged Files... > Date: Tue, 7 Aug 90 13:42:38 EDT > > Ummmm.... It's a good idea, but not for the Macintosh. > > I'm fairly shure that it would be a Bad Thing to have a non-standard > (in the Mac community) version of MacBinary. The existing MacBinary > standard does exactly what is required (for the Mac), and > implimentations are compatible between MacKermit, NCSA Telnet, > MicroPhone, VersaTerm, ... (which is a BIG win). > > So I guess what I would suggest is to use MacBinary to store Mac files > on forign file systems, and do something more reasonable for VMS etc. > It isn't a nice general orthogonal approach, but it also won't screw > up existing usage, and the Mac version of Kermit is the only one that > actually has to deal with it. > Right, the Mac already has MacBinary, and should continue to use it for interoperability with the commercial Mac communication programs that also do MacBinary Kermi transfers. Changing Mac Kermit to do it "the new way" wasn't really a serious suggestion. But the Mac is a good example of the kind of weird file system that needs this kind of treatment. But from the point of view of the protocol, it will be an odd case, like CMS Kermit and SET FILE TYPE V-BINARY. This is not a bad thing. The alternative (adding MacBinary and V-Binary to the protocol) is not a good idea, though, because then every Kermit in the world would need to have SET FILE TYPE MACBINARY and V-BINARY added to it, just so it could send a special file-type attribute. Better to leave things as they stand, and let the user of Mac Kermit or CMS Kermit indicate the special treatment on the computer that knows about it. ------------------------------ > Date: Tue, 7 Aug 90 11:55 MDT > From: Joe Doupnik > Subject: Tagged files proposal > > Nice idea so far, but it lacks most internals. For example, TAGs > implies tags, naturally, and that means a field devoted to the kind-of > information which follows. I suppose that 4 character numbers are ok for > lengths, but the 6 character item seems excessive. > Yes, but why be stingy. Given the way that OS/2 and MS-Windows eat up memory, it's not inconceivable that files of the future could have megabyte-long "resource forks" or whatever... Come to think of it, maybe 6 bytes isn't long enough! > Personally I'd do the organization without a leading count of the > number of tags. An overall count is messy in the program and leads to > trouble if the actual count differs. Rather, I would use TAGging as it was > intended: each field is independent of the others, identifies itself as a > tag-thing and then comes length of tag-dependent data which follows > immediately thereafter. One tag is reserved for "this is the end of > tagging stuff, no tagged data for me either." This places limits on the > number of different tags, but a two byte field ought to cover even the > most obtuse file system. > Having distinguished tags would slow down the innermost loop of Kermit file transfer -- the decoding of packets. It also introduces transparency problems. If the tag is "FOO", then what happens when FOO occurs in the data? Since the file is being transferred in binary mode, the count will be accurate. > There really should be an operating system release level (and > whatever other factors are needed) to pinpoint the file system > particulars. This is machine dependent, of course. > Does everybody think this is important? If so, we have to come up with some kind of "standard" for how to write the OS version. > There should be a way of rejecting a tagged file if one or more of > the tags turns out to be incompatible with the receiver. It wouldn't know > about the problem until that tag is processed. The returned error message, > if any, should be generic enough to not require large amounts of program > space to chat about every possible tag. > The regular old interruption mechanism (X in ACK to D packet) should do the trick. Unfortunately, this does not return an error message. An E packet could also be used: it certainly gets the job done! And it can contain an error message like "Invalid format for tagged file". > I think it is not reasonable to > expect the receiver to backup and write the file as literal binary, tags > and all, if incompatibilities arise in the tag information; that requires > holding far too much information in original form. > Agreed. > Directory information. This is an interesting thing. The reason I > say so is that Novell is now supporting multiple name spaces for files, a > file name structure for each of several file system styles for each real > file. DOS, MAC, and VMS, and probably Unix are the immediate kinds, with > the first two having been implemented already (I run such a system). > Consequently, one tagged item might well be the filename in native form, > with embedded spaces or high-bits or whatever. Btw, this also raises a > point that the tried and true 8.3 filename rule is now out of fashion, and > will be so shortly even on OS/2 based PCs. A Capabilities bit permitting > longer filenames would be nice to have in I/S packets. > Clearly, the meaning of the tags is strictly operating system > dependent. Otherwise we would have to catalogue all the likely o/s' in the > civilized world and that gets out of hand. > So for each OS we need to define the format of the TAG field carefully. Let's experiment with VMS and see how it works, and then refine the idea based on our experience. ------------------------------ > Date: Tue, 7 Aug 90 13:38 MDT > From: Joe Doupnik > Subject: Tagged files proposal, cont'd > > The group: > A couple more points I should have mentioned last time. > The usefulness of tagged files is really limited to machines > running the same version of the same o/s. Sending from a New to an Old > system likely gives troubles from features added to New, and in the other > direction from features obsoleted away in New. > Exchanging files between unlike machines is not so good either, > because once stored as Binary on the destination it can't come back as > Tagged (whose tags??). The fact that a file has its tags held at the front > of the file is not a property of the file (the destination can't remember) > and no one will suggest reading the front of Binary files to discover > embedded tags. > This should not be a problem. Example: VMS Kermit sends a tagged file to DOS. MS-DOS Kermit treats it as a binary file, and stores all the bytes without any knowledge that it contains tags, etc. Later, MS-DOS Kermit sends the file back to VMS Kermit. The user has to say SET FILE TYPE TAGGED to VMS Kermit to make it look in the data for the tags. If the user doesn't give this command, then it's stored -- tags and all -- as a binary file. But in that case, a postprocesssing program can convert it back. Actually, there is one little problem... MS-DOS Kermit sends the file as a binary file, so it puts a "B" in its file-type attribute, whereas VMS Kermit has been told to SET FILE TYPE TAGGED. So which one does it do? Up till now, we have said that the contents of the attribute packet override the current settings on a per-file basis, but in this case we want the opposite to happen. So we must choose between (a) making the current setting take precedence only if it is TAGGED, or (b) adding SET FILE TYPE TAGGED to every Kermit program so that it can put T in its outbound attribute packets, rather than B. (a) probably makes more sense. > Maybe Terry has this figured out, but... What about indexed files? > Some systems treat them as sparce matricies: don't allocate space for > every possible element, but keep a record of which exist and where they > are. I would think that "raw disk i/o" (poor man's attempts of making a > flat file of this stuff) might do the wrong things. > So, we come around to the archiving aspects. I would think that > the code in a Kermit to convert local files to flat archive files is > comparable in size (say half, for using intelligence and skill!) to the > system's own backup programs. I think of doing this stuff across a wire to > another host as akin to putting the file(s) on punched paper tape (no > backing up and redoing a tape block, regardless of finesse). > These are questions for Terry. The VMS version would do essentially what the VMSHEX and VMSDEH programs do now, except skipping the hexification. If VMSHEX/DEH work on ISAM files, then so will this method. - Frank & Chris