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.
>
> 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