FileZilla Simultaneous Transfer Limit and Directory Listing Concurrency

Question

Goal
Determine whether FileZilla’s configured maximum simultaneous transfers also governs the number of concurrent directory listing operations (LIST/MLSD) when navigating remote folders, or whether listings use a separate channel that does not consume transfer slots.
Constraints and Uncertainty
The documentation describes the limit as applying to file transfers and the queue system, but does not explicitly state how directory listings are counted. Behavior may differ between FTP and SFTP, and high‑file‑count servers sometimes exhibit listing timeouts that could be influenced by this setting.
Understanding this interaction is important for avoiding unnecessary bans or timeouts when adjusting the transfer limit on busy servers.

Does each directory listing operation occupy a transfer slot under the “Maximum simultaneous transfers” setting?
If listings are exempt, how are they scheduled relative to queued file transfers?
Can adjusting the simultaneous transfers limit mitigate listing timeout occurrences on servers with extremely high file counts?

Tasadduq Burney · Answer

Answer
Directory listings (LIST/MLSD) do not consume a “Maximum simultaneous transfers” slot; they use the control channel and are counted separately, so the limit only affects data connections for file uploads/downloads.
Explanation
The setting caps concurrent data connections only. LIST and MLSD commands travel over the same control connection that handles login, cwd, and other commands, so they are exempt from the transfer‑slot count. This holds for both FTP and SFTP; in SFTP the listings are part of the SSH session but still do not draw from the data‑connection pool.
If listings are exempt, they are scheduled independently of queued file transfers. The client processes control‑channel commands as they arrive, while data connections are opened on demand for each file transfer. Therefore a high number of directory listings will not block file transfers, nor will it reduce the number of available transfer slots.
Adjusting the simultaneous transfers limit will not directly alleviate listing timeouts that stem from server load, network latency, or the server’s own LIST/MLSD rate limits. It can only prevent the client from opening more data connections than allowed, which may indirectly affect overall throughput but will not change the server’s response time for directory queries.
Verification steps

Open Edit → Options → Transfer Settings and note the current “Maximum simultaneous transfers” value.
Set the limit to 1 while keeping no file transfers active.
Issue a rapid series of directory listings (e.g., using the “Site manager” to browse a folder with many files) and monitor the connection log for “Connection limit reached” messages or timeouts.
If the limit is not reached and no timeouts appear, the listings are truly exempt; if timeouts occur, they are likely caused by other factors.

To confirm the protocol in use, check the connection details (FTP vs SFTP) in the Site Manager; the behavior may differ slightly between them.
Please indicate whether the server you are testing uses FTP or SFTP, as this determines if the control‑channel exemption applies exactly as described.

FileZilla Simultaneous Transfer Limit and Directory Listing Concurrency

Goal

Constraints and Uncertainty

1 answer

Answer

Explanation

Verification steps

Your perspective belongs here.

1 question comment

Key Distinction: Transfer Slots vs. Connection Limits

Where the Bottleneck Actually Lies

Practical Verification