RE: Text file type hint proposal for filexfer

[Richard Whalen <Whalenr%process.com@localhost>]

> From: Jacob Nevins [mailto:jacobn+secsh%chiark.greenend.org.uk@localhost]
> Sent: Monday, October 04, 2004 5:36 PM
> To: ietf-ssh%netbsd.org@localhost
> Subject: Re: Text file type hint proposal for filexfer
> 
> 
> > One other observation:
> > 
> > If you have this attribute, *and* there is some way of knowing the
> > server's line end convention,
> 
> Well, there's the rub, really. How do you do that? You can't 
> rely on the
> "newline" extension being present, or if it is, corresponding 
> with what
> the server will send in binary mode.
> 
> Also: I'm not familiar with VMS, but the impression I have is 
> that line
> breaks there are not represented by a byte sequence at all, but rather
> by something that it's not possible to squirt down an SFTP "binary"
> connection. Hence our having an explicit text mode in SFTP in 
> the first
> place.

Your impression is correct.  Many text files on VMS do not store the line
break sequence.  Files created with a text editor are often stored as
records with a 2 byte count at the start of each record and file attributes
that state that a carriage-return, linefeed sequence will follow each line
when it is displayed on a terminal or printed.  It is also possible for VMS
to store a text file as a stream of bytes (equivalent to the way that Unix
does), with a more complex record structure that includes carriage control
with each record, or as fixed length records in which no carriage control
characters are stored as they can be inferred by the file organization.

This is the basis behind the argument for requesting the server to open
a file in text mode and present it in a canonical way as has been done
with FTP.


----------------------
Richard Whalen
Process Software