Hi Brett, > 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 Actual Rebol ftp cannot work on this type of server :-( Perhaps it can be changed to add a BLIND mode (via /custom) for retrieving/sending files. > 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. It is easy to make the protocol to accept a custom routine to parse raw directory listing. It is more hard for user to write this custom routine :-) > 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) The problem is that NLST returns also dir names like files names, but dirs names are not usable with RETR. :-( > 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... It could be: myfunc: func[][parse-just-all] open/custom ftp://babbabab [parse-list myfunc] or open/custom ftp://babbabab reduce ['parse-list myfunc] > When I look at the number of documents here > http://www.networksorcery.com/enp/protocol/ftp.htm my brain gets scared. And when I read something, I end with more doubts than at start :-) > 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. Numbers errors are magic: they mean everything. :-) I think that giving too much freedom to programmer (an error starting with 5 or an half-error starting with 4 or ...) will lead to caos in a short time. > Does your: > error? try [catch[ something ]] > solve this generally? See my other post. --- Ciao Romano -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
