[Info-vax] Potential loss of data problem in sftp client in TCP/IP Services ?

[Simon Clubley]

On 2012-03-12, JF Mezei <jfmezei.spamnot at vaxination.ca> wrote:
> Simon Clubley wrote:
>
>> However, if you are having problems reproducing it, try entering
>> "ascii dos" or "binary" as a seperate command before the put.
>
>
> I've never used sftp.  Figured it woudl have same inerface as FTP with
> similar commands but just using encrypted links.   What is "ascii dos" ?
>

No. Non-VMS clients just transfer a stream of bytes. The VMS TCP/IP sftp
client has been altered to support various VMS sequential file formats.
In the old version it did this by unconditionally converting the input
file to stream-lf format during transfer.

The new version has a more refined approach allowing greater control
over the line terminator encoding during transfer. "ascii dos" means
the input file is converted to use CRLF terminators during transfer.

>
> You mention variable length files.  Is it possible that the VMS sftp
> client would have trouble counting the number of bytes in the file and
> place the "end of file" at the wrong place ?
>

If it's doing this, which is entirely possible, it's a massive regression
which is silently truncating previously supported file types during
transfer.

> If you CONVERT a RFM=VAR,RAT=CR file to RMF=VAR,RAT=NONE, there should
> be 2 bytes of overhead per record which would match the file size since
><CR><LF> are also 2 bytes long at the end of each line. When using SFTP,
> would the fille be sent completely ? and if it, is it the same missing
> part ?

It's not that simple; there's potentially a line termination conversion
going on during transfer and my experiments show that it doesn't matter
what line termination is active; the input file is still truncated at the
same place.

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world