surgeftp server, bizarre prepending of filename with mget * - Protocols

This is a discussion on surgeftp server, bizarre prepending of filename with mget * - Protocols ; 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 ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: surgeftp server, bizarre prepending of filename with mget *

  1. surgeftp server, bizarre prepending of filename with mget *

    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?



  2. Re: surgeftp server, bizarre prepending of filename with mget *

    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

  3. Re: surgeftp server, bizarre prepending of filename with mget *



    >"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.









  4. Re: surgeftp server, bizarre prepending of filename with mget *

    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


  5. Re: surgeftp server, bizarre prepending of filename with mget *

    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.

  6. Re: surgeftp server, bizarre prepending of filename with mget *

    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

+ Reply to Thread