On 2004-09-20, x@y.org wrote:
: trying to script a setup that will allow me to grab files from a surgeftp
: server,
:
: Version SurgeFTP 2.2k6 Jul 7 2004
:
: i can get a rdir listing of filenames:
:
: -rwxrwxrwx 1 owner group 3585 Sep 17 18:30
: 445284152.G6116RWE.27S
: -rwxrwxrwx 1 owner group 255 Sep 17 16:28
: 445284152.G6116RWE.997
: -rwxrwxrwx 1 owner group 16071 Sep 17 16:28
: 445284152.G6116RWE.ACC
: -rwxrwxrwx 1 owner group 0 Sep 17 16:27
: 45284152.G6116RWE.ANSI203040917-17115188.dat.BID
: -rwxrwxrwx 1 owner group 7238 Sep 17 16:28
: 445284152.G6116RWE.EXT
: -rwxrwxrwx 1 owner group 186 Sep 17 16:28
: 445284152.G6116RWE.REJ
:
: then I try to do execute
:
: ftp mget * t
:
: I get the following msg back for each file :
:
: [type=file;size=7238;modify=20040917212843;create=2 0040917212842;perm=radfw
: 445284152.G6116RWE.EXT]
: GET radfw 445284152.G6116RWE.EXT (binary) (7238 bytes)---> PORT
: 169,254,68,181,6,64
: 200 PORT command successful.
: ---> RETR radfw 445284152.G6116RWE.EXT
: 550 radfw 445284152.G6116RWE.EXT: Cannot open file No such file or directory
:: MESSAGE: radfw 445284152.G6116RWE.EXT: Cannot open file No such file or
: directory
:
: What on earth is this radfw that is prepending itself to my filename, hence
: (I believe) causing the RETR to fail?
:
It appears the server supports MLSD:

http://www.columbia.edu/kermit/newftp.html

The "radfw" bit is the file permissions reported by the server. Why is it
being prepended to the filename? Beats me. Exactly which version of Kermit
are you using? I'd suggest you tell it to:

set ftp debug on

repeat the download attempt, and then send the resulting transcript to
kermit-support@columbia.edu .

- Frank

>"Frank da Cruz" wrote > :
>It appears the server supports MLSD:
> http://www.columbia.edu/kermit/newftp.html
>

Frank, you pointed me in the right direction. I forced NLST,

ftp mget /binary /nlst *

and order was restored to the universe.

If you are interested, I will grab and sanitize logs and provide them to
y'all for debugging info.

I'm testing w/ k95v2.1.3 for implementation on both *nix and m$ platforms.


Thanks for your (unbelievably prompt) and (as always) courteous and helpful
assistance.

Frank da Cruz wrote:
> On 2004-09-20, x@y.org wrote:

> :
> : I get the following msg back for each file :
> :
> :
[type=file;size=7238;modify=20040917212843;create=2 0040917212842;perm=radfw
> : 445284152.G6116RWE.EXT]
> : GET radfw 445284152.G6116RWE.EXT (binary) (7238 bytes)---> PORT
> : 169,254,68,181,6,64
> : 200 PORT command successful.
> : ---> RETR radfw 445284152.G6116RWE.EXT
> : 550 radfw 445284152.G6116RWE.EXT: Cannot open file No such file or
directory
> :: MESSAGE: radfw 445284152.G6116RWE.EXT: Cannot open file No such
file or
> : directory
> :
> : What on earth is this radfw that is prepending itself to my
filename, hence
> : (I believe) causing the RETR to fail?
> :
> It appears the server supports MLSD:
>
> http://www.columbia.edu/kermit/newftp.html
>
> The "radfw" bit is the file permissions reported by the server. Why
is it
> being prepended to the filename? Beats me.

Your example of an MLSD list on the page at
http://www.columbia.edu/kermit/newftp.html shows the various fields
(type=, size=, etc. being separated from each other and from the file
name by a semicolon.

In the list reported above, it appears the perm=radfw at the end of the
list of attributes is separated from the file name only by a space. I'm
only guessing, but I suspect Kermit is splitting the MLSD response into
tokens separated by "=" and ";" and is thus not separating the "radfw"
from the file name.

The draft at
http://www.ietf.org/internet-drafts/...xt-mlst-16.txt says
about MLSD responses:

data-response = *( entry CRLF )

entry = [ facts ] SP pathname
facts = 1*( fact ";" )
fact = factname "=" value

I.e. all facts are terminated with ";" so it would appear that Kermit
is correct and the servers MLSD response is missing the semicolon.

--
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan

Frank da Cruz wrote in message news:...
> On 2004-09-20, x@y.org wrote:
> : trying to script a setup that will allow me to grab files from a surgeftp
> : server,
> :
> : Version SurgeFTP 2.2k6 Jul 7 2004
> :
> : i can get a rdir listing of filenames:
> :
> : -rwxrwxrwx 1 owner group 3585 Sep 17 18:30
> : 445284152.G6116RWE.27S
> : -rwxrwxrwx 1 owner group 255 Sep 17 16:28
> : 445284152.G6116RWE.997
> : -rwxrwxrwx 1 owner group 16071 Sep 17 16:28
> : 445284152.G6116RWE.ACC
> : -rwxrwxrwx 1 owner group 0 Sep 17 16:27
> : 45284152.G6116RWE.ANSI203040917-17115188.dat.BID
> : -rwxrwxrwx 1 owner group 7238 Sep 17 16:28
> : 445284152.G6116RWE.EXT
> : -rwxrwxrwx 1 owner group 186 Sep 17 16:28
> : 445284152.G6116RWE.REJ
> :
> : then I try to do execute
> :
> : ftp mget * t
> :
> : I get the following msg back for each file :
> :
> : [type=file;size=7238;modify=20040917212843;create=2 0040917212842;perm=radfw
> : 445284152.G6116RWE.EXT]
> : GET radfw 445284152.G6116RWE.EXT (binary) (7238 bytes)---> PORT
> : 169,254,68,181,6,64
> : 200 PORT command successful.
> : ---> RETR radfw 445284152.G6116RWE.EXT
> : 550 radfw 445284152.G6116RWE.EXT: Cannot open file No such file or directory
> :: MESSAGE: radfw 445284152.G6116RWE.EXT: Cannot open file No such file or
> : directory
> :
> : What on earth is this radfw that is prepending itself to my filename, hence
> : (I believe) causing the RETR to fail?
> :
> It appears the server supports MLSD:
>
> http://www.columbia.edu/kermit/newftp.html
>
> The "radfw" bit is the file permissions reported by the server. Why is it
> being prepended to the filename? Beats me. Exactly which version of Kermit
> are you using? I'd suggest you tell it to:
>
> set ftp debug on
>
> repeat the download attempt, and then send the resulting transcript to
> kermit-support@columbia.edu .
>
> - Frank

Pardon me for butting in, but if this is what was really sent, it looks like the
semi-colon was omitted after the perm parameter.
following copied from above:
> : [type=file;size=7238;modify=20040917212843;create=2 0040917212842;perm=radfw
> : 445284152.G6116RWE.EXT]

Regards...Dan.

x@y.org wrote:
>>"Frank da Cruz" wrote > :
>>It appears the server supports MLSD:
>> http://www.columbia.edu/kermit/newftp.html
>>
>
>
> Frank, you pointed me in the right direction. I forced NLST,
>
> ftp mget /binary /nlst *
>
> and order was restored to the universe.
>
> If you are interested, I will grab and sanitize logs and provide them to
> y'all for debugging info.
>
> I'm testing w/ k95v2.1.3 for implementation on both *nix and m$ platforms.
>
>
> Thanks for your (unbelievably prompt) and (as always) courteous and helpful
> assistance.

There are several bugs in Kermit 95 2.1.3 related to the processing of
FTP operations such as MSLD. The fixes for these problems are available
for a fee. See http://www.columibia.edu/~jaltman/ for a list of the
available fixes and how you can obtain them.

Jeffrey Altman
Kermit 95 Author


--
-----------------
This e-mail account is not read on a regular basis.
Please send private responses to jaltman at mit dot edu