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

FTP scheme was Re: Reading empty directories via FTP error

 [1/26] from: atruter::labyrinth::net::au at: 14-Nov-2003 11:16


Brett wrote
> Ashley's 226 error was solved (see patch in REBOL library). Ashley also > had > the same error as Carl's (NLST) - which hopefully now is solved. Ashley's > third problem was a general one about having had an FTP error, FTP could > become unusable for the rest of the session - which I think you have > identified in your error handling comments.
Hey, you know my issues better than me now! ;) Assuming a combination of patches from you, Carl, Romano, and others correct these (and other) various problems, how much of the FTP scheme handler code is being patchd? 25%, 50%, 75%? Not withstanding the vagaries of the FTP standard / protocol, have we reached the point where a number of FTP related functions should be replaced by a merge of the various patches out there? Or have I underestimated the complexity of the task? I'll volunteer to test anything against the two sites I have access to (the second of which has a subset of the problems identified above). Regards, Ashley

 [2/26] from: brett:codeconscious at: 14-Nov-2003 13:33


> Hey, you know my issues better than me now! ;)
:-)) I know about many issues now I'm not sure I wanted to know about!
> Assuming a combination of patches from you, Carl, Romano, and others > correct these (and other) various problems, how much of the FTP scheme > handler code is being patchd? 25%, 50%, 75%?
I can't speak for others, but the patch I loaded into REBOL.org for the 226 multiline handling literally adds 1 or 2 refinement! depending on your REBOL version. My NLST handling patch (see later) adds about 5 lines of copied code. My error handling patch (see later) replaces about four words and add a line of code.
> Not withstanding the vagaries of the FTP standard / protocol, have we > reached the point where a number of FTP related functions should be > replaced by a merge of the various patches out there? Or have I > underestimated the complexity of the task?
I'm not really sure there are too many patches out there for FTP apart from what I'm doing at the moment. Merging the disparate elements I'm creating would make sense into a single patch. It would even be good to have an original source of the entire fixed protocol to use, but I'm not sure how the licensing and copyrights goes with that for publication to the library.
> I'll volunteer to test anything > against the two sites I have access to (the second of which has a subset > of the problems identified above).
Excellent. Here you go then (watch line wrap) - try these together Run each with a PRINT DO X in a new sessnon - before you try FTP. http://www.rebol.org/cgi-bin/cgiwrap/rebol/download-a-script.r?script-name=p atch-ftp-226-handling.r http://www.codeconscious.com/ftp-testing/patch-ftp-nlst-handling.r http://www.codeconscious.com/ftp-testing/patch-ftp-error-handling.r Now I'm not sure you'll have any luck given your reply to Carl about the cutting of the NLST part. I can only hope that with all three patch files run together your problem will be solved holistically :-) Testing the error handling defect is a pain because as Romano pointed out it is hard to replicate. I hope though you have a test case to run unpatched vs patched. Here is mine (where test-a and test-b should not exist): site: ftp://USER:[PASS--codeconscious--com]/ print mold read site make-dir join site %test-a/test-b/ print mold read site probe read join site %test-a/test-b/ print mold read site probe read join site %test-a/ print mold read site probe read join site %test-b/ print mold read site Running this unpatched cause the FTP protocol to fail on the last line - saying it can't login. After patching it seems to work as expected except that the make-dir problem Romano described already has not been changed - I haven't got a patch for that yet! Regards, Brett.

 [3/26] from: carl:cybercraft at: 24-Dec-2003 22:47


On 14-Nov-03, Brett Handley wrote:
> Here you go then (watch line wrap) - try these together > Run each with a PRINT DO X in a new sessnon - before you try FTP. >
http://www.rebol.org/cgi-bin/cgiwrap/rebol/download-a-script.r?script-name=p
> atch-ftp-226-handling.r > http://www.codeconscious.com/ftp-testing/patch-ftp-nlst-handling.r > http://www.codeconscious.com/ftp-testing/patch-ftp-error-handling.r
I tried them and ftp worked with no problems on the two sites I've talked about till now. But I have access to one other server, so yesterday I thought I'd try it with your parse-dir-list fix - but imediately noticed access via REBOL's FTP wasn't returning all the file-names in the first directory I looked at! This is nothing to do with your code, as it happens with REBOL's original code. There's 24 files and directories in the directory when I look at it with my FTP client, but REBOL only returns 10 of them. Anyone heard of this problem before? -- Carl Read

 [4/26] from: rotenca:telvia:it at: 14-Nov-2003 12:54


Hi Carl,
> But I have access to one other server, so yesterday I thought I'd try > it with your parse-dir-list fix - but imediately noticed access via
<<quoted lines omitted: 3>>
> in the directory when I look at it with my FTP client, but REBOL only > returns 10 of them. Anyone heard of this problem before?
This could be another bug of ftp: parse rules are not always correct. I sent a feedback report about this a little time ago: 7/2001 ;-) Must be said that ftp output of different servers is hard to reduce to a standard set of rules. Perhaps ftp should accept custom parse rules. --- Ciao Romano

 [5/26] from: brett:codeconscious at: 15-Nov-2003 1:37


Hi Carl,
> I tried them and ftp worked with no problems on the two sites I've > talked about till now.
<<quoted lines omitted: 5>>
> in the directory when I look at it with my FTP client, but REBOL only > returns 10 of them. Anyone heard of this problem before?
Eeek! As Romano pointed out - parse rules. But I'm not so happy that there is no error generated. Carl can you try this on the server with the above problem - all it does is poke in NET-LOG tracing statements to emit the results from LIST and NLST (file-list really). If the info returned by LIST or NLST is not sensitive it would good to see it (permissions/names changd for safety if necessary) and/or perhaps you could send it "off-list". http://www.codeconscious.com/ftp-testing/patch-ftp-list-logging.r Regards, Brett.

 [6/26] from: maximo:meteorstudios at: 14-Nov-2003 10:13


might want to include the stuff I did to enable CHMOD after xfer... -MAx
> -----Original Message----- > From: Brett Handley [mailto:[brett--codeconscious--com]]
<<quoted lines omitted: 40>>
> Run each with a PRINT DO X in a new sessnon - before you try FTP. > http://www.rebol.org/cgi-bin/cgiwrap/rebol/download-a-script.r
?script-name=p atch-ftp-226-handling.r http://www.codeconscious.com/ftp-testing/patch-ftp-nlst-handling.r http://www.codeconscious.com/ftp-testing/patch-ftp-error-handling.r Now I'm not sure you'll have any luck given your reply to Carl about the cutting of the NLST part. I can only hope that with all three patch files run together your problem will be solved holistically :-) Testing the error handling defect is a pain because as Romano pointed out it is hard to replicate. I hope though you have a test case to run unpatched vs patched. Here is mine (where test-a and test-b should not exist): site: ftp://USER:[PASS--codeconscious--com]/ print mold read site make-dir join site %test-a/test-b/ print mold read site probe read join site %test-a/test-b/ print mold read site probe read join site %test-a/ print mold read site probe read join site %test-b/ print mold read site Running this unpatched cause the FTP protocol to fail on the last line - saying it can't login. After patching it seems to work as expected except that the make-dir problem Romano described already has not been changed - I haven't got a patch for that yet! Regards, Brett.

 [7/26] from: rotenca:telvia:it at: 14-Nov-2003 17:22


Where is your ftp stuff? --- Ciao Romano

 [8/26] from: maximo:meteorstudios at: 14-Nov-2003 13:43


I had sent it to the list a while ago. I guess I'll just fix something I think is wrong with the way I'm sending the command and upload it to rebol.org... now if I can just remember my password... ;-) I'll do it tonight. -MAx --- You can either be part of the problem or part of the solution, but in the end, being part of the problem is much more fun.

 [9/26] from: carl:cybercraft at: 24-Dec-2003 22:47


On 15-Nov-03, Brett Handley wrote:
> Hi Carl, >> I tried them and ftp worked with no problems on the two sites I've
<<quoted lines omitted: 19>>
> "off-list". > http://www.codeconscious.com/ftp-testing/patch-ftp-list-logging.r
I get a file-not-found with that I'm afraid. URL wrong or script not uploaded, perhaps? For what it's worth, this is what trace/net returns from my third server...
>> read -url-
URL Parse: -user- -password- -url- none web/ none Net-log: [ ["PORT" port/locals/active-check] "200"] Net-log: "200 PORT command successful." Net-log: [ ["TYPE A"] ["200"]] Net-log: "200 Type set to A." Net-log: [ ["LIST"] ["150" "125"]] Net-log: {150 Opening ASCII mode data connection for file list.} Net-log: [ none "226"] Net-log: "226 Transfer complete." == [ -10 files, not 24 like it should be- ] -- Carl Read

 [10/26] from: brett:codeconscious at: 15-Nov-2003 13:59


> I get a file-not-found with that I'm afraid. URL wrong or script not > uploaded, perhaps?
Oops - rectified now. Regards, Brett

 [11/26] from: carl:cybercraft at: 24-Dec-2003 22:47


On 15-Nov-03, Brett Handley wrote:
> Hi Carl, >> I tried them and ftp worked with no problems on the two sites I've
<<quoted lines omitted: 19>>
> "off-list". > http://www.codeconscious.com/ftp-testing/patch-ftp-list-logging.r
Okay - got it now. Running it output... Inserted NET-LOG for received NLST results. and reading the directory from that site returned... URL Parse: -user- -password- -url- none web/ none Net-log: ["Opening" "tcp" "for" "FTP"] Net-log: [ none ["220" "230"]] Net-log: {220 ProFTPD 1.2.5 Server (ProFTPD) [217.206.220.106]} Net-log: [ ["USER" port/user] "331"] Net-log: "331 Password required for -user-." Net-log: [ ["PASS" port/pass] "230"] Net-log: {230-****************** Site Administrator FTP instructions ******************} Net-log: " " Net-log: { PLEASE ensure that you are in the /web directory before uploading files} Net-log: { to be viewable from the web server root directory.} Net-log: " " Net-log: { There is also a user area (which you may be in now) which will allow you} Net-log: { to test uploaded files at http://<your.site.domain>/~/-user- before} Net-log: " uploading them to the /web directory." Net-log: " " Net-log: { If you are having problems viewing the /web area then try setting passive } Net-log: " mode in your ftp client." Net-log: " " Net-log: { *************************************************************************} Net-log: " " Net-log: "230 User -user- logged in." Net-log: [ "SYST" "*"] Net-log: "215 UNIX Type: L8" Net-log: [ ["PORT" port/locals/active-check] "200"] Net-log: "200 PORT command successful." Net-log: [ ["CWD" either empty? port/path ["./"] [join "./" port/path]] 250 ] Net-log: "250 CWD command successful." Net-log: [ ["TYPE A"] ["200"]] Net-log: "200 Type set to A." Net-log: [ ["LIST"] ["150" "125"]] Net-log: {150 Opening ASCII mode data connection for file list.} Net-log: [ none "226"] Net-log: "226 Transfer complete." == [-10 files instead of 24-] Turning on passive mode (ie... system/schemes/ftp/passive: true ) makes no difference - it still returning just the 10 files. This any help? ... -- Carl Read

 [12/26] from: brett:codeconscious at: 15-Nov-2003 21:35


Hi Carl,
> Running it output... > > Inserted NET-LOG for received NLST results.
Sorry, my little patches are getting too complex now, this output shows that there logging for LIST is missing - the patch must have decided that things were too different - so it did not insert the line. I know you've figured out how to do it manually in the protocol, so could you try inserting: net-utils/net-log ["LIST results:" file-list] directly before if empty? file-list [ within the parse-dir-list function. With this change in place, you should be able to see the re-assembled directory listing from the server that will be parsed. If it amuses you, you could poke the net-utils/net-log line with custom output wherever else you think it would be useful in the protocol for sorting this out. :-) Regards, Brett. ----- Original Message ----- From: "Carl Read" <[carl--cybercraft--co--nz]> To: <[rebol-list--rebol--com]> Sent: Saturday, November 15, 2003 6:41 PM Subject: [REBOL] Re: FTP scheme was Re: Reading empty directories via FTP error

 [13/26] from: carl:cybercraft at: 24-Dec-2003 22:47


On 15-Nov-03, Brett Handley wrote:
> Hi Carl, >> Running it output...
<<quoted lines omitted: 11>>
> With this change in place, you should be able to see the > re-assembled directory listing from the server that will be parsed.
Okay - that gives...
>> read -url-
URL Parse: -user- -password- -url- none web/ none Net-log: [ ["PORT" port/locals/active-check] "200"] Net-log: "200 PORT command successful." Net-log: [ ["TYPE A"] ["200"]] Net-log: "200 Type set to A." Net-log: [ ["LIST"] ["150" "125"]] Net-log: {150 Opening ASCII mode data connection for file list.} Net-log: [ none "226"] Net-log: "226 Transfer complete." Net-log: ["LIST results:" { drwxrwsr-x 2 212 217 1024 Jan 25 2002 -dir- drwxrwsr-x 4 212 217 1024 Jan 25 2002 -dir- drwxrwsr-x 2 212 217 1024 Jan 25 2002 -dir- drwxrwsr-x 2 212 217 1024 Jan 25 2002 -dir- drwxrwsr-x 2 212 217 1024 Jan 25 2002 -dir- -rw-rw-r-- 1 99 users 2095 Jan 24 2002 -file- drwxrwsr-x 2 212 217 1024 May 17 2001 -dir- -rw-r--r-- 1 212 users 138 May 10 2001 -file- -rw-r--r-- 1 212 217 5528 May 10 2001 -file- drwxrwxr-x 2 99 99 7168 Nov 8 08:37 -dir- }] == [-10 files that should be 24-]
> If it amuses you, you could poke the net-utils/net-log line with > custom output wherever else you think it would be useful in the > protocol for sorting this out. :-)
I played around with it a bit but didn't get any useful results. I wondered if re-writing the... while [line: system/words/pick port/sub-port 1] in parse-dir-list to grab every char that's sent would be useful to see if it's missing anything, but I've not looked into it yet. Would you know how to do that? Either REBOL's skipping stuff it shouldn't be - or not asking for stuff it should be asking for - I'm assuming... -- Carl Read

 [14/26] from: g:santilli:tiscalinet:it at: 15-Nov-2003 13:55


Hi Carl, On Saturday, November 15, 2003, 1:17:58 PM, you wrote: CR> Net-log: ["LIST results:" { CR> drwxrwsr-x 2 212 217 1024 Jan 25 2002 -dir- CR> drwxrwsr-x 4 212 217 1024 Jan 25 2002 -dir- CR> drwxrwsr-x 2 212 217 1024 Jan 25 2002 -dir- CR> drwxrwsr-x 2 212 217 1024 Jan 25 2002 -dir- CR> drwxrwsr-x 2 212 217 1024 Jan 25 2002 -dir- CR> -rw-rw-r-- 1 99 users 2095 Jan 24 2002 -file- CR> drwxrwsr-x 2 212 217 1024 May 17 2001 -dir- CR> -rw-r--r-- 1 212 users 138 May 10 2001 -file- CR> -rw-r--r-- 1 212 217 5528 May 10 2001 -file- CR> drwxrwxr-x 2 99 99 7168 Nov 8 08:37 -dir- CR> }] CR> == [-10 files that should be 24-] Do the remaining files start with a dot? (i.e. ".something") Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

 [15/26] from: rotenca:telvia:it at: 15-Nov-2003 15:56


Hi all,
> CR> Net-log: ["LIST results:" { > CR> drwxrwsr-x 2 212 217 1024 Jan 25 2002 -dir-
<<quoted lines omitted: 9>>
> CR> }] > CR> == [-10 files that should be 24-]
The problem with directory listing in the ftp protocol is known: rfc 959: Since the information on a file may vary widely from system to system, this information may be hard to use automatically in a program, but may be quite useful to a human user. New commands have been proposed, see the abbstract of http://www.ietf.org/internet-drafts/draft-ietf-ftpext-mlst-16.txt In order to overcome the problems caused by the undefined format of the current FTP LIST command output, a new command is needed to transfer standardized listing information from Server-FTP to User- FTP. Commands to enable this are defined in this document. I think that there is little to do for the existing ftp protocol. Also because NLIST is not always implemented, if LIST is implemented. And this happens also if the http://www.wu-ftpd.org/rfc/rfc1123.html says (1989) that NLIST MUST be implemented. --- Ciao Romano

 [16/26] from: carl:cybercraft at: 24-Dec-2003 22:47


Appologies to Brett, Gabriele and any others who've responded to my missing file-names problem. The cause was REBOL's FTP path and my FTP clients' paths don't match. The directory I was looking at with my clients was site/web/ but with REBOL this needed to be site/../../web/ (ie, back up two directories.) With REBOL, site/web/ is actually pointing to site/../../user/web/ where user is a directory set aside for testing and its web directory actually contains 10 files and directories that match site/../../web/ Blugh!
>From this I assume my FTP clients can detect they need to start up two
directories from the host's URL, whereas REBOL can't. Would this be possible? Back to Brett's original ask - namely to test FTP after running these patches... ---8<--- print do http://www.rebol.org/cgi-bin/cgiwrap/rebol/download-a-script.r?script-name=patch-ftp-226-handling.r print do http://www.codeconscious.com/ftp-testing/patch-ftp-nlst-handling.r print do http://www.codeconscious.com/ftp-testing/patch-ftp-error-handling.r ---8<--- Happily, reading directories whether empty or otherwise works fine on all my sites after running those. -- Carl Read

 [17/26] from: nitsch-lists:netcologne at: 16-Nov-2003 9:58


Am Sonntag, 16. November 2003 05:12 schrieb Carl Read:
> Appologies to Brett, Gabriele and any others who've responded to my > missing file-names problem.
<<quoted lines omitted: 9>>
> directories from the host's URL, whereas REBOL can't. Would this be > possible?
Newer rebols have it. try ftp://server// instead of ftp://server/ . a double slash behind the server-name. or explained in an other way: join ftp://server/ %/usr/local/ -Volker

 [18/26] from: g:santilli:tiscalinet:it at: 16-Nov-2003 11:01


Hi Carl, On Sunday, November 16, 2003, 5:12:08 AM, you wrote: CR> From this I assume my FTP clients can detect they need to start up two CR> directories from the host's URL, whereas REBOL can't. Would this be CR> possible? This is because REBOL does a "CWD ~" and considers ftp://somesite/ to be the user home directory. I think this is how FTP URLs are expected to be; normal FTP clients do not use URLs though, and consider "/" to be the site root and not the user home directory. Making REBOL work the other way around in unpractical because you wouldn't have any way to (automatically) knowing where your home directory is by just using URLs. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

 [19/26] from: rotenca:telvia:it at: 16-Nov-2003 18:54


Hi,
> Also because > NLST is not always implemented, if LIST is implemented. And this happens
also
> if the http://www.wu-ftpd.org/rfc/rfc1123.html says (1989) that NLIST MUST
be
> implemented.
I was wrong, I have no evidence that NLST is not handled by some ftp servers. 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. 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. 3) Use a custom flag "NLIST" to get names with NLST instead of LIST. Examples open ftp://bla.bla.bla ;use LIST open/custom ftp://bla.bla.bla [NLST] ;use NLST -> no info about dir and files, no slash at the end of dir names Any ideas? --- Ciao Romano

 [20/26] from: moliad:aei:ca at: 16-Nov-2003 15:00


>=== Original Message > >Hi,
<<quoted lines omitted: 5>>
> ;use NLST -> no info about dir and files, no slash at the end of dir > names
That's a VERY good idea, then things like my up and coming chmod patch can also be added easily, without playing around with url specifics. Like: also open/custom ftp://bla.bla.bla [NLST EXE BIN] CONCERNING MY FTP PATCH ------------------------ BTW I had to choose between: A new kitchen floor and a happy wife... OR A ftp fix post and a happy list... seems like my wife's cause won, again ;-) so I should be posting my ftp patch which transfers file with a chmod for executable scripts (cgi ;-) sometime soon. I also think that the computer on which the only version of the patch exists at home is now offline... so , I'll have to scratch a little more than expected. OTH: ------------- I've been hard at work with Phil Bevan testing/using the mailreader.r tool (which is getting better almost daily ;-). he just released 3.1.1 It now supports external user VID styles, and I'm trying to make my contextual popup menu pluggable in the default distro... hope Phil wont be mad at me for saying all of this out loud ;-) I'm just so proud of all the little features which he added, almost just because I asked, in such a short period. Its now my full-time default mailer. As you can see, it now even supports indentation. - MINI STEEL PROJECT UPDATE - I've also been working on the library description web page and the library.r tool itself, it should be out rather shortly. Very busy even if not overly demonstrative. -MAx

 [21/26] from: brett:codeconscious at: 17-Nov-2003 11:44


Hi Carl,
> Happily, reading directories whether empty or otherwise works fine on > all my sites after running those.
Ah good. So far, it looks like between us on this thread there is at least 3 maybe 4 different server behaviours for FTP. Although we haven't established yet the nature of our connections (proxy?/passive?). Regards, Brett

 [22/26] from: ed:brittlestar at: 16-Nov-2003 20:38


I recall reading that the Netscape developer (pre-AOL days) responsible for their browser FTP code was incredulous when it was decided that they would recode their entire browser from scratch. He had written ugly code to carefully manage 60 or so nonstandard variations of the protocol implemented by FTP server software. Reichart's company wrote a commercial/sharware FTP client a while back (IIRC), so it must be possible to do a reasonably good implementation. Ed ----- Original Message ----- From: "Brett Handley" To: <[rebol-list--rebol--com]> Sent: Sunday, November 16, 2003 7:44 PM Subject: [REBOL] Re: FTP scheme was Re: Reading empty directories via FTP error

 [23/26] from: brett:codeconscious at: 17-Nov-2003 12:52


Hi Ed,
> I recall reading that the Netscape developer (pre-AOL days) responsible
for
> their browser FTP code was incredulous when it was decided that they would > recode their entire browser from scratch. He had written ugly code to > carefully manage 60 or so nonstandard variations of the protocol
implemented
> by FTP server software.
Sixty! Wow.
> Reichart's company wrote a commercial/sharware FTP client a while back > (IIRC), so it must be possible to do a reasonably good implementation.
Yes, FTP Gadget. Regards, Brett.

 [24/26] 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

 [25/26] from: greggirwin:mindspring at: 16-Nov-2003 23:09


Hi Max, mac> I've been hard at work with Phil Bevan testing/using the mac> mailreader.r tool (which is getting better almost daily ;-). Sounds great! Thanks to both of you for pursuing it. I keep meaning to start using it myself, just haven't gotten to it yet. :( -- Gregg

 [26/26] from: rotenca:telvia:it at: 17-Nov-2003 17:22


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

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted