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

[Simon Clubley]

On 2012-03-12, Albrecht Schlosser <vms-news at go4more.de> wrote:
> On 12.03.2012 16:12, Simon Clubley wrote:
>> I am experiencing a file truncation problem with a TCP/IP engineering
>> image version of the TCP/IP Services sftp client and I am wondering
>> if anyone here can reproduce it.
>>
>> Try using the sftp client to send something small (so that it's easy to
>> check; I am using my login.com) to a Linux sftp server.
>>
>> When I do this (both in "ascii dos" mode and binary mode) the last
>> few dozen bytes of my login.com are lost during transfer.
>
> I can't help with your particular question, but is this "few dozen
> bytes" potentially related to the number of lines in the file, maybe
> with a factor of 1, 2, or 4? This would be a hint that it has to do
> with file organization and/or [CR/]LF "translation". It could also
> be related to even or odd record sizes (1 byte padding in text files).
>

Congratulations, that appears to be the common factor.

> I'd do another test with a stream lf file to check as well.
>

I converted my login.com to stream_lf using convert and a FDL and the
full length transferred ok.

Can anyone else duplicate this on V5.7 ECO3 ?

I heard back from the support person and it doesn't appear to be
truncating the file on V5.7 ECO2 (he hasn't tried ECO3 yet), although
(reading between the lines) it appears V5.7 ECO2 still had the old
transfer code in the sftp client.

In the old transfer code (present up to the most recent sftp client
versions) all input files, regardless of format, got converted to
stream_lf format during transfer, resulting in a LF as a line
terminator in the destination file. The ascii command, while
documented, was ignored.

It appears that in the latest engineering image something is going
wrong during the conversion which results in the file been truncated
both in binary and ascii dos mode. I don't know if it's some timing
issue (which might explain way it wasn't caught during testing) or a
more general problem.

Thanks,

Simon.

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