|Subject:||Re: File never closed on broken connection|
|Posted by:||Remy Lebeau \(TeamB\) (firstname.lastname@example.org)|
|Date:||Wed, 10 Sep 2008|
"Johan Nilsson" <input@home_delete_.se> wrote in message
> If the client connection is abnormaly lost during the upload, it seems
> that the file is never closed by the server, but remains open until the
> server is closed (Active=False).
> I've waited several days, and it seems that the file is never closed.
The only way that could be happening is if the server is not freeing the
TFileStream objects it uses internally. There are several try..finally
blocks in the transfer code, so I find it unlikely that it would never be
doing that when errors occur. On the other hand, the OS can't detect
abnormal disconnects in a timely manner, so it is possible for Indy not to
detect the disconnects for several hours, but it certainly should be after
> Is there any TimeOut-property?
There is the TIdIOHandler.ReadTimeout property. However, TIdFTPServer does
not expose direct access to the IOHandler of the secondary connections that
are used for transfers. You could use an accessor class to reach the
protected TIdFTPServerContext.DataChannel.FDataChannel member, but there is
no specific event to tell you when a transfer is starting. The closest I
see is the TIdFTPServer's OnDataPortBeforeBind and OnDataPortAfterBind
events. The Sender parameter would be the TIdFTPServerContext object that
is opening a new socket.
File never closed on broken connection posted by Johan Nilsson on Tue, 9 Sep 2008