Re: FTP strangeness

In article <eelvpv$fum$1@xxxxxxxxxxxxxxxxx>, david20@xxxxxxxxxxxxxxxx writes:
In article <12gskj8rnfikj57@xxxxxxxxxxxxxxxxxx>, "Gremlin" <not-here@xxxxxxxx> writes:
Hi

I put these suggestions to SmartFTP who replied"....Whatever your other
source says we believe they are wrong and it seems they are unable to
understand the RFCs correctly. Furthermore 5xx is always an error code.
Listing an empty existing directory shouldn't return an error code.

We will no further comment on this issue. Thank you for your understanding."

So, it looks like SmartFTP is off the list as a client for VMS, Cerberus
appears to be a fine server, but I need a client. So, any other
suggestions? Firezilla does the same thing I notice. All the clients I
have tried seem to stop when they get a 550 from VMS.

The issue of 550 for an empty directory is a different issue from saying that
servers cannot issue a 550 reply to a LIST command.
As demonstrated more than just VMS ftp servers do the latter - for situations
where a directory doesn't exist or a particular file is specified on the LIST
command which doesn't exist.
(A GUI based FTP client may not need to know about this since it may restrict
listing to the current directory and just move to the new directory before
listing it - but commandline ftp clients generally support listing files in
other directories and even the specification of a full filename on the LIST
command).


Whether Listing an empty directory should produce an error reply-code is,
as far as I am aware, not defined by the RFCs.
It can easily be argued both ways.

Note. The default text associated with error 550 says :-

Requested action not taken.
File unavailable (e.g., file not found, no access)


There is no way for the client to know whether the directory really is empty
or whether file protections prevent the user accessing files in the directory.
Hence it can be argued that it is reasonable to return this code for an
apparently empty directory.
It is even more reasonable to return this error reply-code if the user has
specified the full filename on the LIST command and the file does not exist or
is not accessible.


In any case an FTP client should comply with the robustness principle of RFC
1123 section 1.2.2

"Be liberal in what you accept, and conservative in what you send"



I haven't used it myself but one of my colleagues seems to like Core FTP Lite
which is a GUI based ftp client available for free download from
http://www.snapfiles.com/get/coreftp.html

(which seems to follow the robustness principle and just ignores the 550
returned by VMS for the empty directory).


I've just downloaded what I assumed was the ftp client you are using
smartFTP from
http://www.smartftp.com/download/

With

Alpha2:ucx sh ver

Compaq TCP/IP Services for OpenVMS Alpha Version V5.3 - ECO 2
on a AlphaServer 2100 5/300 running OpenVMS V7.3-1

and accessing directories on an ODS-5 disk I don't seem to have any problems
accessing an empty directory.

And a quick check shows the same is true for an ODS-2 disk.

Hence I'm not sure why you are getting a problem.
Which version of TCPIP and VMS are you running the ftp server under ?

By default the GUI client seems to move into the directory using a CWD
command and then issues the LIST command successfully.

If I stay in the top-level directory and type the full spec for the empty
directory in the file-selection window then it seems to have no trouble
displaying the empty directory - the LIST command completes successfully
without any 550 being displayed.

I've just checked again using the VMS ftp client and it seems I made a small
mistake it is only the ls command corresponding to NLST which returns a 550
when accessing an empty sub-directory. The dir command

FTP> dir [.test]
200 PORT command successful.
150 Opening data connection for [.test] (158.94.0.14,54856)

Total of 0 files, 0/0 blocks

226 LIST Directory transfer complete.
32 bytes received in 00:00:00.01 seconds (2.84 Kbytes/s)

corresponding to LIST does not return a 550 code but just an empty listing.





David Webb
Security team leader
CCSS
Middlesex University




Cheers

"Gremlin" <not-here@xxxxxxxx> wrote in message
news:12gs1flfi0jls16@xxxxxxxxxxxxxxxxxxxxx
Thanks for that info, I have passed it on to the SmartFTP support (without
names!) to see if that helps them sort this out for VMS.

Cheers

<david20@xxxxxxxxxxxxxxxx> wrote in message
news:eejp7r$ps9$1@xxxxxxxxxxxxxxxxxxxx
In article <12gmuf2rbaj5d4@xxxxxxxxxxxxxxxxxx>, "Gremlin"
<not-here@xxxxxxxx> writes:
My reading of the RFC, possibly flawed, is that for the LIST command, 550
is
not one of the "valid" returns from the server (OVMS). Have I misread or
misunderstood this?


What permanent error reply-code (ie 5xx number) do the manufacturers of
SmartFTP suggest an ftp server should send ?

Also note that RFC 959 is NOT the final word on all things to do with
FTP.
Please see RFC 1123 which states :-



"
4.1.2.11 FTP Replies: RFC-959 Section 4.2, Page 35


A Server-FTP MUST send only correctly formatted replies on
the control connection. Note that RFC-959 (unlike earlier
versions of the FTP spec) contains no provision for a
"spontaneous" reply message.



A Server-FTP SHOULD use the reply codes defined in RFC-959
whenever they apply. However, a server-FTP MAY use a
different reply code when needed, as long as the general
rules of Section 4.2 are followed. When the implementor has
a choice between a 4xx and 5xx reply code, a Server-FTP
SHOULD send a 4xx (temporary failure) code when there is any
reasonable possibility that a failed FTP will succeed a few
hours later.

"

550 Requested action not taken.
File unavailable (e.g., file not found, no access).

is a valid RFC 959 section 4.2 reply-code and hence MAY be used when
needed.
The fact it is not listed against the LIST command in section 5.4 of rfc
959
would appear to be overridden by the above statement in RFC 1123.


David Webb
Security team leader
CCSS
Middlesex University




"Cluster-Karl" <karl.rohwedder@xxxxxx> wrote in message
news:1158316788.056323.186190@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Here is part of RFC 959:0

RFC 959 October
1985
File Transfer Protocol
550 Requested action not taken.
File unavailable (e.g., file not found, no access).

Btw. also the HGFTP client sends a 550 error.

regards Kalle







.

Relevant Pages

  • Re: Job Stream via FTP
    ... This is a specific instance of the general rule that, if an FTP client doesn't understand the command you wish to send to the FTP server, you should "quote" it, as it were. ...
    (bit.listserv.ibm-main)
  • Re: FTP transfer problems
    ... The MPEiX FTP client is simply terminating ... If it is then what command does one run from ... * To join/leave the list, search archives, change list settings, * ...
    (comp.sys.hp.mpe)
  • Re: issue with ftp::Quote STATUS .
    ... I am trying to use the ftp:Quote option to send native FTP commands to ... Works from the ftp command line on tyhe same machines. ... you the actual protocol interactions as the ftp client is interpreting ... There is an FTP 'STAT' command, but I don't know if it does what ...
    (comp.lang.tcl)
  • Re: Net::FTP Wierdness; or Not.....
    ... When they dont, the error messages seem to be the response ... from the FTP server acknowledging my previous command, or empty. ...
    (comp.lang.perl.misc)
  • Re: Delete command in FTP
    ... > Is there a way to delete all the files on a ftp ... > server without specifying delete commands for each file name? ... FTP client, you would normally turn off the interactive prompting ("Delete ... "prompt" command, and follow that up with the "mdelete" command - multiple ...
    (microsoft.public.inetserver.iis.ftp)