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

[Jan-Erik Soderholm]

Simon Clubley wrote 2012-03-13 10:48:
> On 2012-03-12, David Froble<davef at tsoft-inc.com>  wrote:
>>
>> I'm still trying to understand the problem.  You indicate that you had been using V5.6
>> ECO5.  Are you saying the problem exists in this version?
>>
>
> No, the file truncation problem does not exist in the sftp image supplied
> with ECO5, but other different problems do exist, which is why the latest
> Engineering images were loaded onto the system in question.
>
> This file truncation problem is clearly a very recent problem. I am still
> waiting to hear back from HP, so in the meantime I am trying to find out
> if anyone else can duplicate this using the most recent TCP/IP ECO (V5.7
> ECO3).

I tried to run a few quick tests on my 8.4 (Alpha) TCPIP 5-7 ECO3 system,
but gave up after a number of different errors like "wrong SSH2 version".
I never understood what was the problem... :-)

In my case, since the thought is that this it not a server-side problem,
I simply runed against user at localhost. That might not work anyway if you
think that one has to run against another box to get the error.

Jan-Erik.


>
>> Last year I implemented a small application that uses SFTP to get and put files from and
>> to a non-VMS system.  I needed to use a batch command file for SFTP since things ware
>> happening in a batch job, not from a terminal.  I have not had any problems in either
>> direction.  On the non-VMS system I do not know either the system, nor the file format.  I
>> suspect some form of Unix as the directory / path structure used "/".
>>
>> Now, the batch file I use for input to SFTP gets automatically translated into stream_lf
>> by SFTP, but as far as I can see, the actual files transfered do not.
>>
>
> That's very different from my experiments. On the older versions of the sftp
> client, all input files are converted to stream_lf during transfer. HP even
> have a command procedure floating around internally which allows you to send
> a file as a stream (CRLF terminated) format file using this older version.
>
> It works by converting the file to stream format and then altering the file
> attributes to make it appear as a stream_lf file so that it doesn't get
> converted during transfer.
>
>> The files I transfer all have records of the same length, but are sequential variable
>> files on VMS regardless of direction of transfer.
>>
>> So what I'm trying to understand is, are you having trouble with all sequential variable
>> files, or just those files where individual records are of differing length?
>
> All the files I need to transfer have records of different length so that
> is what I have been testing.
>
> Simon.
>