Re: 9.0.x DevSnapshot: Bugfixes in IdTCPConnection and IDFTPServer

Giganews Newsgroups
Subject: Re: 9.0.x DevSnapshot: Bugfixes in IdTCPConnection and IDFTPServer
Posted by:  Remy Lebeau (Indy Team) (no.spam@no.spam.com)
Date: Thu, 5 Oct 2006

"Ulf Jaenicke-Rößler" <u…@insynergie.de> wrote in message
news:1969F730700AE340u…@insynergie.de...

> I was able to fix it by checking the size of read data, which is
necessary,
> because the while loop doesn't break anymore if the connection has
> been close gracefully.

Yes, it does.  You are using an older version that does not have the
official fix applied to it.  This issue has already been fixed awhile ago,
by changing this block of code:

    if not (E is EIdConnClosedGracefully) or not AReadUntilDisconnect then
begin
        raise;
    end;

To this instead:

    if (E is EIdConnClosedGracefully) and AReadUntilDisconnect then begin
        Break;
    end else begin
        raise;
    end;

> The second bug occurs, if a FTP client tries to rename a file on a
> FTP server. The connection seems to hang. The reason is, that
> TIdFTPServer.CommandRNTO only sets a numeric return code,
> but no reply.

The reply text is irrelevant, and not required, in most commands, including
RNTO.  Only the reply code is needed and required.  The lack of reply text
will not hang the connection.  Especially since TIdFTP does not actually use
the reply text for anything at all.  So whatever hang you may be
experiencing has to be caused by something else.

Also, TIdFTPServer uses its ReplyTexts property to automatically fill in a
default reply text when a command handler does not provide any text, so your
"fix" does not actually do anything that TIdFTPServer cannot already do for
you.

Gambit

Replies

In response to

9.0.x DevSnapshot: Bugfixes in IdTCPConnection and IDFTPServer posted by Ulf_Jaenicke-Rößler on Thu, 05 Oct 2006