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

[Steven Schweda]

> Can anyone else duplicate this on V5.7 ECO3 ?

   If I still had patch access, then I might give it a try,
but I don't.

> [...] TCP/IP engineering image version of the TCP/IP
> Services sftp client [...]

   And I certainly don't have one of those.

> Although I am still on V5.6 ECO5, the Engineering supplied
> sftp image has significant enhanced functionality.  [...]

   This is the program which is truncating your files?  This
must be some new meaning for "enhanced".

> To try and reproduce:
> [...]

   You can't create a guaranteed-to-fail file, and make it
available?


> [...] What is "ascii dos" ?

   You couldn't read the HELP text provided?


> sftp doesn't have an option to send text files while
> translating line termination.

   The protocol spec may not describe such a mode, but that
can't stop a client (or server) program from trying to adjust
the line endings.


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

   This should not be amazing.  The VMS C RTL does things
with Stream_LF files which it doesn't do with even Stream or
Stream_CR, let alone non-Stream, variable-length-record
files.  The exact behavior depends on the file attributes,
and on how the file is opened, and almost none of the details
is intuitive.  With no access to the SFTP client source code,
it's hard to do more than guess, but many non-obvious
problems are easy to encounter.  (Recent experience with
GnuPG v. text files, and with Zip v. Stream or Stream_CR with
long records, suggests that there are many more ways to do
things wrong than there are to do them right, and that the
variety of files needed for thorough testing is larger than
one might expect.)

> Can anyone else duplicate this on V5.7 ECO3 ?

   I wouldn't worry much about that.  If you can take N
files with different attributes which BACKUP /COMPARE and/or
DIFFERENCES (and/or GNU "diff") says are equivalent, and the
SFTP client can't send the data properly for M of them (where
M > 0), then you would seem to have found a bug/limitation in
the SFTP client.

   Knowing nothing, my guess would be that the old code
handled the file-attribute differences by doing an effective
CONVERT-to-Stream_LF, and the new code thinks that it's
clever enough to skip that step, but it's not.  And the
testing (before yours) was inadequate to catch the
problem(s).  (But what do I know?)