Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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:
> 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
> 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 :-/ (
> 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 my brain gets scared. Interesting, this post I came across may be a clue as to why the NLST success check was {<> #"5"} 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
> catch is unuseful. But in other cases must be checked. The problem is that
> exists a thow-on-error somewhere, or some function attributes which change
> error behaviour when it is cupled with return.
Does your: error? try [catch[ something ]] solve this generally? Regards, Brett