"API" <ari.pikivirta@kolumbus.fi> wrote in message
news:45e8550d@newsgroups.borland.com...
> i tried to look the difference between indy9 and indy10 ftp server
> retrieve function, but there seemed not to be anything special -
> at least i didn't find any.
There are very large differences between them. Asside from all of the
added features in 10 (especially the new TIdFTPFileSystem
architecture), TIdFTPServer in 10 also uses a different threading
model than 9 did for transfers. For every data transfer that a client
requests, 9 would spawn a new worker thread to perform the transfer in
the background, and then let the command handler exit immediately. In
10, no worker thread is used at all anymore. The transfer is
performed inside the command handler instead.
> anyway, the problem is that firefox (as very bad ftp client) cannot
> change/list any directory because of it first tries to get the
filesize,
> then retrieve the file and after that it will change dir and list
dir.
> it's getting stuck on the retrieve file now.
Then firefox is likely doing something wrong in its commands, and/or
your event handlers are implemented wrong. Please show your actual
code. Did you try using a packet sniffer to watch the actual packet
traffic back and forth? TIdFTPServer in 10 is a lot more stable than
it was in 9. In fact, TIdFTPServer has received a large amount of
focus in 10's development because it is one of Indy's most extensive
components.
> on indy9 it worked alright by just setting the vstream to zero as
> there is really no file, because it's directory
The same applies to 10 as well.
> but on indy 10 it doesn't continue from that.
Yes, it does. When you set VStream to nil, TIdFTPServer sends the
same error message back to the client that 9 did.
> i checked the codes; and it's sending exactly same 550 reply
> both on indy9 and indy10 in case no stream defined
Then the fault is on FireFox's side. Again, you need to look at the
actual command/reply packets to find the differences between the two
versions.
Gambit
