[REBOL] Re: FTP scheme was Re: Reading empty directories via FTP error
From: brett:codeconscious at: 17-Nov-2003 12:54
Hi Romano,
> I was wrong, I have no evidence that NLST is not handled by some ftp
servers.
The RFC you refer to says:
The following commands and options MUST be supported by
every server-FTP and user-FTP, except in cases where the
underlying file system or operating system does not allow or
support a particular command.
My take out from that is that any specific server-FTP or user-FTP will
support NLST and LIST except when it does not. (-:
Perhaps an example of this might be where directory permissions are such
that a user is allowed to read a file they target exactly, but not allowed
to read directory contents. As an example search for "blind" in this:
http://www.castaglia.org/proftpd/doc/contrib/ProFTPD-mini-HOWTO-Limit.html
> I have thought to some strategies for the LIST/NLIST problem
>
> 1) Correct the parse rules. But it is hard to handle all the possible
> variants.
It is good to correct bugs already existing and known. As for variants, as
you've pointed out, the existing protocol has two sets of rules - perhaps
allowing the user to be able to add a new set later as required (a loadable
parse-rule set) would be useful? I cannot imagine that there would be many
of these.
> 2) Make first NLST to be sure to have at least a correct list of names and
> then do the LIST to get info about single names. The problem of NLST is
that
> it does not distingue between dir and files, so if user assumes that
> directories names end with slash can be foolish.
The rfc says "NLST reply usable in RETR cmds" - ie no directory attribute
information. Looking at various comments, it appears the intention of NLST
is to return usuable arguments for RETR and for possibly implementing MGET
commands. Apparently though, some people may have implemented NLST to look
like LIST :-/ (http://www.csh.rit.edu/projects/solo/news.php?item=11)
> 3) Use a custom flag "NLIST" to get names with NLST instead of LIST.
Examples
I keep forgetting about the /custom refinement. I've never really spent the
time to investigate it. Perhaps it could be used to "name" a set of
parse-rules the user knows will work [MSFTP] or [BIZZARE-FTP] where
bizzare-ftp is an object stored under system/schemes/ftp...
> Any ideas?
When I look at the number of documents here
http://www.networksorcery.com/enp/protocol/ftp.htm my brain gets scared.
Interesting, this post I came across may be a clue as to why the NLST
success check was {<> #"5"} http://dbforums.com/t944661.html
It makes wonder even more about what Ashley's server is responding to a NLST
with.
A question for you some time back you wrote:
> This is a thing to test. In the specific connections case, under 1.2.10
the
> catch is unuseful. But in other cases must be checked. The problem is that
can
> exists a thow-on-error somewhere, or some function attributes which change
the
> error behaviour when it is cupled with return.
Does your:
error? try [catch[ something ]]
solve this generally?
Regards,
Brett
