-2

I have a simple question. I work with Delphi 2010.

I have an FTP client inside my software. When I do work with an IIS-based FTP, it works OK.

I changed my FTP server last week. Now I have a Linux server with ProFTPD.

When I do work with this FTP server, it works, but it downloads corrupted files.

I've noticed using the debugger that the function idFTP.Size returns -1. So, I use the Size number, returned by the Indy FTP directory parser when I idFTP.list the files. Using this way, files are downloaded in a corrupt state.

However, using other FTP programs, files are downloaded ok.

with idFTP1 do
begin
 AutoLogin := False;
 IPVersion := Id_IPv4;
 Passive := True;
 TryNATFastTrack := true;
 Port := 21;
 Host := '192.168.121.221';
 Username := 'flxupgrader';
 Password := 'avaricia';
 Connect;
 login;
 TransferType := ftBinary;
 BeginWork(wmRead);
 Get('/_Enterprise/141010.zip',
    'E:\Usuarios\Pablo\141010.zip');
 EndWork(wmRead);
 Disconnect;
end;

When I execute this code using the FTP server in my Linux with ProFTP FTP server, my ZIPs are downloaded corrupted. You can not extract anything from it, "CRC error".

Important: Using Windows Explorer to access the FTP server to download a file: it works ok. The file is 24525K. Using my program with Indy 10 to download that file, the downloaded file is 24616K and it is corrupt.

  • It's virtually impossible to debug code that you haven't shown us, or information you haven't provided (for instance, whether the file is binary or text, or an idea of what "corrupted" means). – Ken White Oct 14 '14 at 16:34
  • I edited the question with more information about the problem. @Remy: New problems arises: I changed the FTP Server. Now I have a VSFTP. Using Windows Explorer: files are downloaded ok. With my program with Indy 10.5.5, I get this error "exception class EIdReplyRFCError with message 'Failed to open file'". COMPILING WITH DELPHI XE3: It works fine with ProFTP. It does not work with VSFTP. – Pablo Romero Oct 15 '14 at 13:50

2 Answers2

0

TIdFTP.Size() returns -1 when either:

  1. the FTP server reports any reply code other than 213 for the SIZE command.

  2. the FTP server reports a reply code of 213, but its reply text cannot be parsed into an Int64.

That being said, Size() is strictly for users to call when needed. TIdFTP itself does not use Size() at all, it does not play any role in actual transfers. Size() sets the TransferType property to ftBinary before sending the SIZE command, then restores the previous value if needed. Some FTP servers do not allow the SIZE command in ASCII mode, for instance.

When you transfer a file, you have to make sure you are using the correct TransferType for the type of file you are transferring. The fact that your "corrupted" file is larger than then source file suggests that you are transferring the file in ASCII mode (which is the default type, per the FTP spec), so bare CR and LF byte octets are being converted to CRLF sequences during the transfer. Only textual files should ever be transferred in ASCII mode, and only if cross-platform line breaks are an issue. Anything else should be transferred in BINARY mode instead so byte octets are transferred as-is.

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
  • I solved my problem by the nightmare :) of installing the latest Indy 10 on Delphi 2010. All works ok now. I keep my ProFTP FTP server on my Linux. Thks. – Pablo Romero Oct 15 '14 at 19:16
0

I have got the similar issue. The problem was IdFtp was changing line endings from unix to windows in binary files. The solution is to change TransferType to ftBinary