sftp issues

[SAMI AHMAD]

hi can someone tell me what does the "*"  means in file listing in sftp ?  the file with the "*"  showing up is having issues being transferred

sftp > ls -l 

-rw-r-----         ABC1.TXT;1

-rwxrwxrwx     DEF3.TXT;1*      <<<<< file which is failing ftp .

-rw-r--------     JEB4.TXT;2

[SDIH1]

The * at the end of the filename means a file, a / at the end means a directory.
This seems to be more or less documented in the ssh/sftp RFC´s
but in my experience it´s best to leave ls -l alone when sftpíng to VMS.
If you want a friendly output, you might be able to get it using
ssh you@vmshost dir/size/sec or similar.

[x2084]

The appended '*'  flags a file as executable, which is consistent with the protection mask showing the 'x'. This seems to be the same as with  'ls -F' on Unix, which appends characters to classify a file.

[SAMI AHMAD]

we are unable to get this file as sftp is appending another version "011" to the file name  and saying it cant find the file, but the file is there .

 is there some local parameter controlling this ?   

>>>>> sftp> get TRAN_20110630_1145.011

>>>>> fcr_parse_raw: >>>>> /pasdisk4/leeway/outgoing/ready/tran_20110630_1145.011.011 (src): >>>>> no such file (server msg: 'syserr: no such file or directory

[Steven Schweda]

   With my weak psychic powers, I don't know whether the SFTP client or
server is a VMS system, or which version of anything is running
anywhere.

> we are unable to get this file [...]

   Get _which_ file?  From where?  What does a directory listing on the
server system say?

> [...] no such file or directory

   How should I know if this file really exists?  Do you have any
evidence that it does?

> [...] get TRAN_20110630_1145.011

> [...]/tran_20110630_1145.011.011

   Is someone case-sensitive?  Do you need to use quotation marks
somewhere?

[SAMI AHMAD]

the client and server are both VMS systems running alpha 7.3-1  ,     The file we are trying to transfer is

TRAN_20110630_1145.011;1

Directory PASDISK4:[LEEWAY.INCOMING.TRANSFER]

PLAZ_20051211_0020.030;1

4

PLAZ_20051231_0015.030;1

4

SSH2.DIR;1 1

TCPIP$SSH_SFTP-SERVER2.LOG;2

2

TCPIP$SSH_SFTP-SERVER2.LOG;1

1

TICK_20110721_1211.011;1

4

TRAN_20110630_1145.011;1

32

TRAN_20110720_0030.031;1

525

TRAN_20110720_1230.032;1

211

Total of 9 files, 784 blocks.

PASY$

[Steven Schweda]

> the client and server are both VMS systems running alpha 7.3-1  ,

   That's a start.  More helpful might be:

      tcpip show version

and, possibly:

      sftp "-V"

> Directory PASDISK4:[LEEWAY.INCOMING.TRANSFER]

  Can't see the file ownership or permissions that way, but my guess
would be that the SFTP software is buggy.  At VMS V7.3-1, it could be
very old, and old TCPIP software can be much worse than newer versions.
If you ask for "TRAN_20110630_1145.011", and the SFTP client seems to be
asking for "tran_20110630_1145.011.011", then I'd call it a bug.  A
(much) newer version seems to look much different from yours:

alp $ tcpip show version

  HP TCP/IP Services for OpenVMS Alpha Version V5.6 - ECO 5
  on a COMPAQ Professional Workstation XP1000 running OpenVMS V8.3   

alp $ sftp "-V"
alp$dkc0:[sys0.syscommon.][sysexe]tcpip$ssh_sftp2.exe: SSH Secure Shell OpenVMS
(V5.5) 3.2.0 on COMPAQ Professional Workstation  - VMS V8.3

alp $ sftp sms@alp-l

@ SYS$MANAGER:ANNOUNCE.TXT   [Later versions aren't bug-free, either.]
sftp> cd itrc
ALP$DKC0:[SMS.ITRC]
sftp> get a_b_c.123
a_b_c.123                         |    14B |   0.0 kB/s | TOC: 00:00:01 | 100%
sftp> quit


alp $

   Does it work better for a file name like "abc.def" than it does for
"abc.123"?  It could be confused by a name extension which could be a
version number.

   In any case, I'd look for a TCPIP ECO which is newer than what you
have now.