Re: Problems with Indy 10 FTP component

Giganews Newsgroups
Subject: Re: Problems with Indy 10 FTP component
Posted by:  Jeremy Darling (jdarli…@eonclash.com)
Date: Wed, 2 Nov 2005

Well you found the right group :).

First off you need to upgrade to the lastest Indy 10 snapshot, as these are
probiably already fixed in their (10.1.5 daily dev snapshot).  Then re-build
and see if the problem persists.  If it does then post back :).

Make sure that you COMPLETELY remove Indy before installing the new version.

Jeremy

"Nikolay Samofatov" <nickol…@sympatico.ca> wrote in message
news:64A8EC5037E0E240nickol…@sympatico.ca...
> Hi!
>
> I am trying to implement a simple FTP server with Indy 10.0.52 with
> moderate success so far.
>
> Problems so far:
>
> 1. ftp.proxy in monitoring mode dies when used against IdFTPServer. The
> reason for death is that PWD returns empty string.
>
> The latter is caused by apparently missing line of code here:
> --
> procedure TIdFTPServerContext.ReInitialize; begin
>  inherited; // Added by Nikolay Samofatov
>
>  FDataType := ftASCII;
>  // FDataMode := dmStream;
>  FDataPort := 0;
>  FDataStruct := dsFile;
>
>  FPASV := False;
>  FEPSVAll := false;
>
>  FDataProtection := ftpdpsClear;
>  DataPBSZCalled := False;
>  FDataProtBufSize := 0;
> end;
> ---
>
> 2. When I do "LIST -la" in Far Manager command line against my server the
> server dies with Access Violation at the following line of code:
> ---
> procedure TIdFTPServer.CommandLIST(ASender: TIdCommand); ...
>          //it should be safe to assume that the FDataChannel object
> exists because
>          //we checked it earlier
>          FDataChannel.Data := LStream;
>          FDataChannel.FFtpOperation := ftpRetr;
>          FDataChannel.OKReply.SetReply(226, RSFTPDataConnClosed);
>          FDataChannel.ErrorReply.SetReply(426,
> RSFTPDataConnClosedAbnormally); ...
> --
>
> Access violation happens on the line right after the comment because
> FDataChannel is nil.
>
> 3. It is not straightforward to implement pipe access via IdFtpServer. The
> problem is that Indy makes use of TStream.Size for no good reasons.
>
> To work it around I had to implement TStream.Seek like this:
> --
> const
>  STREAM_GROWTH_INCREMENT = 65536;
>
> function TCachedPublicationObject.SeekStream(
>  Stream : TCachedStream; Offset: Integer; Origin : Word): Integer; var
>  SavedSize : Integer;
> begin
>  case Origin of
>    soFromBeginning:
>      Stream.FPosition := Offset;
>    soFromCurrent:
>      Stream.FPosition := Stream.FPosition + Offset;
>    soFromEnd:
>      begin
>        // Grow stream in increments of 64k. This keeps Indy 10 happy and
> parallelizm feature works.
>        FDataStreamMutex.Enter;
>        try
>          SavedSize := FDataStream.Size;
>          repeat
>            if FDataStreamInvalid then
>              raise EReadError.Create('Error creating replication delta
> package. Please examine log file for details');
>
>            if FDataStreamComplete or (FDataStream.Size >= SavedSize +
> STREAM_GROWTH_INCREMENT) then
>            begin
>              Stream.FPosition := FDataStream.Size;
>              break;
>            end;
>
>            FMoreDataEvents.Add(Stream.FWakeupEvent);
>            FDataStreamMutex.Leave;
>
>            Stream.FWakeupEvent.WaitFor(INFINITE);
>
>            FDataStreamMutex.Enter;
>          until False;
>        finally
>          FDataStreamMutex.Leave;
>        end;
>      end
>  end;
>  Result := Stream.FPosition;
>  FAccessDateTime := Now;
> end;
>
> But this looks like a dirty hack if nothing else.
>
> Nikolay Samofatov

Replies

In response to

Problems with Indy 10 FTP component posted by Nikolay Samofatov on Tue, 01 Nov 2005