To: papval@otenet.gr (Vassilis Papathanassiou)
From: dlanor@oden.se (Ronald Andersson)
Organization: 
Subject: Re: STinG (and more)
X-Mailer: NEWSie Version 0.82 (Atari)


Hi Vassilis

>>This is a really short reply (more later) just to correct a misunderstanding
>>you seem to have concerning the FTP standard.
>>
>I wish it was a standard. Having worked with UNIX machines for some years,
>i'm afraid there is yet another representation for the FTP LIST command,
>than the standard ls -l command. Even RFC 959 has some errors (?). At least
>servers i've checked have different responces sometimes.

That is very true, but the server must only follow one of these, and it is
up to the client to adapt, provided that the standard used is at all UNIX.
That is what you did not fulfil when using the CR+LF combination.

Obviously you should look for the most common format used by real servers
and implement something similar, to avoid client failure.  But you do not
have to support more than a single variant of that format because there
is no way for a client to tell you to change anyway.

The server _decides_ the format, the client _interprets_ it.


>>>>----- snip ----- re: FTP-Server
>>>
>>>Peter has now checked it, look at the answer:
>>>---> I checked the server, and found it works beautifully. Well done !
>>
>>And I agree, it is very nice indeed.  If only we could be rid of the few
>>remaining problems...  It really should work with all the clients, even
>>if none of them are perfect, because they all work reasonably well on the
>>real network.
>>
>Hmm, again i'm not looking for good words for the server, i just sent it
>to you, to see the different aspect of the subject. In this form, all
>command line clients work fine, and of course they expect UNIX formating.

Yes, but CLI clients are usually used very interactively, so that results
depend much more on the responses of a human being.  Naturally his ways
of interpreting the listings appearing on screen are more flexible than
what a program can manage.  Thus he will probably type the correct names
even when surrounded (in the listing) by stuff that does not fit his own
notion of a normal list format (even if that stuff were real garbage).

He will just pick out the names he wants visually, ignoring the rest, and
type the correct names into his various commands.  MG-FTP and the rest of
the automated clients have to extract the names from the listings, and
interpret their meaning (links, files etc) according to some surrounding
text.  Since they do not have a human 'overview', a single unexpected
character can sometimes catch them off balance, so they fall down on the
job, which is precisely what happens.


>As for the clients, John Rojewski asked the server to test it, aFTP works
>fine and MG-FTP has real problems. After our last discussion, i spent
>some time on the Internet with it. Well, sometimes it 'eats' dir entries,
>sometimes doesn't display the dir at all, it took a file and then suspented,
>etc, etc. Checked with ftp..berlin, ftp.ibp.fr etc. If it works for you...
>(but i admit, dir display is, hmm, better. :-)

I know it has some real problems, and some of the combinations of the
display options do not work at all, causing all operation to fail.

Nevertheless there is a clear contrast.  On the net it _sometimes_
fails, but it happens every single time with your server.  Like I
said before, MG-FTP has not managed to transfer a single file via
your server on my site, and I have tried quite a lot.


>----- snip ----- re: UNIX response
>>(Because badly informed clients only provide 'vanilla' functions.)
>>[But then again, I'm very fond of (real) vanilla...  ;-)  ]
>>
>[What about chocolate... ;-)]

I love chocolate too.


>Seems to me that i'd never got a 'real' LIST file from the clients. So, one
>thing i'm going to do (unless you can send me such a file), is to write a

Sorry, I don't have any myself either.

>small (very small) ftp client to connect to a server and get a 'real' LIST
>UNIX file. (and who knows, we might end up with yet another FTP client :-)

The idea seems very good, though I think/hope you do not mean _a_ server
and _a_ file, but several examples to give you a good idea of the normal
format that you need in your server.  As for a new client, why not ?

Perhaps it would be smart to have a small CLI-like client, in a window
of course, allowing the interactive use I described above where a human
handles the thinking and the client just provides the interface.  In fact
that is the only kind of client which can work at all with servers that
use non-standard formats (I don't mean yours here!) and protocol variants.

Automated clients often fail in these situations, whereas a human can
pick out the parts of the listings that do make some twisted sense.
As long as the command interface itself is compatible this will work.


>----- snip ----- re: SYST command
>SYST command is actually not so usefull. When the response was ATARI, no one
>seemed to bother. Even WS-FTP (Windows) worked fine (It has more than 15
>'standards') MG-FTP 1.4 was the first that refused to connect.

Unrecognized system types invariably means either of three things:

1: Immediate logout.  (not good, and no longer common)
2: Implied use of defaults for some system 'assumed' normal  (not good)
3: Implied switch to tolerant 'vanilla' mode, using the most common formats
   and smart filtering.  This is better, but still not fail-safe.
   (And none of our clients are really that smart, even if they try.)

The smarter clients will attempt to cope with lists that differ from
standards, but that does not mean that the SYST info is meaningless.

A client must parse the lines to extract file/folder/link names from
all other info, of which there is a lot.  And that other info looks
entirely different on different systems (eg: the UNIX access flags).
With the wrong SYST info some of that stuff will be taken as names.
(For some special cases I mean, not for all.)

Thus we get 'file names' like "rwxr-xr-x" if you see what I mean ?
The details naturally vary with the system types, and the degree
by which unrecognized types vary from the client assumptions.


>I'm now writing a CAB.OVL (!), hmm, more multitasking friendly, but i hope

Very interesting.  I hope to hear more on that later then.


>i'll send you yet another version of FTP Server, maybe tomorrow. (don't take
>my word for that, i'll try :-)

Ok, I'm in no real hurry though I'd like it ASAP of course.
