ftp scheme (cont.)

empty list of files. I think this is entirely reasonable, so in this latest FTP scheme I've changed the logic to use NLST only if parsing of LIST results fails. That is, if nothing is returned successfully I consider that an empty directory, if something is returned but our parse rules fail then I use NLST. Because it is simpler, NLST is unlikely to fail (if it is implemented on the server). If by chance both do actually fail, then I raise an error. I've also factored out the common logic as I see it into a separate function to see how LIST and NLST are so similiar. I've also merged the various patches added a little more network logging and changed [error? catch value ] sequences to [error? try [catch value]] pending Romano's comments on this error handling strategy. do http://www.codeconscious.com/ftp-testing/ftp-proposed.r trace/net true read ftp://.... Regards, Brett.

You come to my side about patches :-) I did not want to rewrite by scratch the whole ftp protocol, only to reorganize the code to do better and wider patches.

Could be, the problem is: 1) user ask a dir read ftp://aaa.bbb.ccc/pub/ the dir is [a/ b/ c d] 2) LIST fails 3) NLIST does not fail 4) user copy is [a b c d] 5) user thinks these are 4 files (he can't know that LIST has failed) I prefer the custom approach, so the user knows what he is doing and what he receives. But now i have another idea: to use the NLST only for file retrieve not for dir list. A problem i know with this approach is:

make object! [ size: none date: none type: 'file ] but usenet is a directory.

Try [catch blk] catches almost any throwed or maked errors in my test. There are only 2 general cases i know in which it does not work, but they are not presents (AFAIK) in the protocols, so we can almost sure. --- Ciao Romano

Jackpot! This seems to have corrected all the issues I had on "my" two servers. Well done. Regards, Ashley

Works fine with all my three servers Brett. Good work. So, should I make this my perminant ftp patch? I'm losing track of which is which. :) Carl.

-- Carl Read

Ah good. It incorporates all the others, but I'd like to see bits of mine welded onto Romano's so that result becomes the patch to use. Stay tuned :-) Regards, Brett.