TIDFTP sending short files goes to timeout

[Dany40]

Hi;

I use a TIDFTP client in a RadStudio 10.4 project that connects to a FileZilla Server for sending thoudands of little files (1kb to 4 or 5 MB). The client is set to send in pasive mode and bynari mode, using PUT:

Code:

Ftp.Put(sSoruceFile, sTargetFile, False, -1);

In the very big number of files it sends every week, 3 or 4 different and small files (2 kb in size) appeared that could not be transferred to that server; FileZilla is receiving them, sure in only one package as those files are very little in size; but after the client reaches the 60 seconds timeout, the Put raises a read error. When I see at the server side, the file only have 1300 bytes, when the original file is 2406 bytes.

Using one of the files that fails, I can reproduce the same 100% of the times I try. I attached here a test file.

FileZilla server is 1.12.1 version, and it is running on a Windows 11 PRO virtual machine and behind a NAT.

Thank you in advanced for any idea or clue I can follow!

[rlebeau]

In the very big number of files it sends every week, 3 or 4 different and small files (2 kb in size) appeared that could not be transferred to that server; FileZilla is receiving them, sure in only one package as those files are very little in size; but after the client reaches the 60 seconds timeout, the Put raises a read error. When I see at the server side, the file only have 1300 bytes, when the original file is 2406 bytes.

The size of the file should not matter. But, this behavior implies to me that the entire file is not being sent to the server, and the data connection is not being closed at the end of the file, but the client is trying to read a reply from the server that is not being sent since the server is still expecting data to arrive.

What is the actual read error? Is it an error reading the local file, or an error reading a socket? Do you have a log of the FTP traffic for the file(s) that fail?

[Dany40]

Thank you.
The message in the exception error is: "Read timed out" and the error code is 150.
I noted that most bytes in the file is #0, and if I change all the #0 with other value then the file is sent without error.
Other thing: all the FileZilla servers that does this error are running in Windows 11 PRO virtual machines that are running into a LINUX-PROXMOX environment. If I send the same file to the same version of FileZilla but running in other Windows environments, then the file is sent without problems. Here you have the logfile done on the client-side. First it creates a target folder, then if the file already exists it is delteted, then the file is sent.

Stat Connected.
Recv 15/01/2026 10:19:08: 220-FileZilla Server 1.12.1<EOL>220 Please visit https://filezilla-project.org/<EOL>
Sent 15/01/2026 10:19:08: HOST xxx.xxx.xxx.xx<EOL>
Recv 15/01/2026 10:19:08: 500 Wrong command.<EOL>
Sent 15/01/2026 10:19:08: USER xxxxxxxxxx<EOL>
Recv 15/01/2026 10:19:08: 331 Please, specify the password.<EOL>
Sent 15/01/2026 10:19:08: PASS xxxxxxxxxxxxxxxxxxx<EOL>
Recv 15/01/2026 10:19:08: 230 Login successful.<EOL>
Sent 15/01/2026 10:19:08: FEAT<EOL>
Recv 15/01/2026 10:19:08: 211-Features:<EOL> MDTM<EOL> REST STREAM<EOL> SIZE<EOL> MLST type*;size*;modify*;perm*;<EOL> MLSD<EOL> AUTH SSL<EOL> AUTH TLS<EOL> PROT<EOL> PBSZ<EOL> UTF8<EOL> TVFS<EOL> EPSV<EOL> EPRT<EOL> MFMT<EOL> filezilla.wildcards 0<EOL>211 End<EOL>
Sent 15/01/2026 10:19:08: OPTS UTF8 ON<EOL>
Recv 15/01/2026 10:19:08: 202 UTF8 mode is always enabled. No need to send this command<EOL>
Sent 15/01/2026 10:19:08: TYPE I<EOL>
Recv 15/01/2026 10:19:08: 200 Type set to I<EOL>
Sent 15/01/2026 10:19:08: SYST<EOL>
Recv 15/01/2026 10:19:09: 215 UNIX emulated by FileZilla.<EOL>
Sent 15/01/2026 10:19:09: TYPE I<EOL>
Recv 15/01/2026 10:19:09: 200 Type set to I<EOL>
Sent 15/01/2026 10:19:09: TYPE A<EOL>
Recv 15/01/2026 10:19:09: 200 Type set to A<EOL>
Sent 15/01/2026 10:19:09: EPSV<EOL>
Recv 15/01/2026 10:19:09: 229 Entering Extended Passive Mode (|||50986|)<EOL>
Sent 15/01/2026 10:19:09: NLST PRU<EOL>
Recv 15/01/2026 10:19:09: 150 Starting data transfer.<EOL>226 Operation successful<EOL>
Sent 15/01/2026 10:19:09: TYPE I<EOL>
Recv 15/01/2026 10:19:09: 200 Type set to I<EOL>
Sent 15/01/2026 10:19:09: CWD PRU<EOL>
Recv 15/01/2026 10:19:09: 250 CWD command successful<EOL>
Sent 15/01/2026 10:19:09: SIZE PRU1.TXT<EOL>
Recv 15/01/2026 10:19:09: 213 1300<EOL>
Sent 15/01/2026 10:19:09: DELE PRU1.TXT<EOL>
Recv 15/01/2026 10:19:09: 250 File deleted successfully.<EOL>
Sent 15/01/2026 10:19:09: EPSV<EOL>
Recv 15/01/2026 10:19:09: 229 Entering Extended Passive Mode (|||50939|)<EOL>
Sent 15/01/2026 10:19:09: STOR PRU1.TXT<EOL>
Recv 15/01/2026 10:19:09: 150 About to start data transfer.<EOL>
Sent 15/01/2026 10:21:09: QUIT<EOL>
Stat Disconnected.

[Dany40]

Let me add another thing: all the servers that cannot receive this file from a TIdFTP client, can receive the same file using any other client.

[Dany40]

Hello!

I add here an image I get when debuggin Indy code, I think this mean Indy is sending the all the bytes. Please let me know if it helps or if I need to add here more information to help. Thank you!

[rlebeau]

I noted that most bytes in the file is #0, and if I change all the #0 with other value then the file is sent without error.

TIdFTP doesn't care what the file's bytes are. It just reads the file's raw bytes and sends them as-is.

Other thing: all the FileZilla servers that does this error are running in Windows 11 PRO virtual machines that are running into a LINUX-PROXMOX environment. If I send the same file to the same version of FileZilla but running in other Windows environments, then the file is sent without problems.

That sounds like an environmental issue and not an Indy issue. Have you reached out to the FileZilla devs?

Here you have the logfile done on the client-side. First it creates a target folder, then if the file already exists it is delteted, then the file is sent.

I don't see anything out of the ordinary in that log, except for the missing final response to the file transfer, which is where the timeout error is occurring. TIdFTP is sending the file, but the server is not finalizing the transfer.

Let me add another thing: all the servers that cannot receive this file from a TIdFTP client, can receive the same file using any other client.

That makes no sense.

Have you tried using Wireshark to capture the raw TCP traffic? Make sure TIdFTP is actually transmitting all of the expected file bytes over the data connection, and that a closure of the data connection (FYN packet) is being transmitted at the end of the transfer.

I add here an image I get when debuggin Indy code, I think this mean Indy is sending the all the bytes.

All that means is that the file bytes are being given to the socket. It is then up to the OS to make sure they are actually transmitted to the server.

[Dany40]

Yes. But I cannot understand why with other 3 ftp clientes I can send the file without problems.

[rlebeau]

Yes. But I cannot understand why with other 3 ftp clientes I can send the file without problems.

As per my earlier suggestion - please use Wireshark to capture the raw TCP data for the failing transfers and see what is actually different between the various clients for the same files. Something has to be different to cause your issue. TIdFTP is quite mature and how it transfers files hasn't changed in a long time, so I doubt it has a bug that is mishandling the transfers, but anything is possible. I need more detail to troubleshoot

[Dany40]

Thank you; here I am sending you the WhireShark log.

---

Let me clarify something. My ftp client first is asking to the server the file size of a possible file that already exists on target folder. In returns a size of 1300 bytes, and this is from the file that failled in the previous intent. So the client ftp will try to delete it, and then it will try to send.

[Dany40]

I see "MSS=1300"
Does this mean the sender (TIdFTP) proposes sending segments of up to 1300 bytes?