Timeout occurs on Dir call with large number of files

Question

Calling Dir() in the past has been fine but this directory has grone to be VERY VERY large. It seems as though there's some type of timer the kills the Dir call after a certain amount of time.

I tried setting Timeout=0 on the Client but that did not solve the problem.

Any thoughts?

Thanks,
- Kevin

Answer 1

There are no explicit restrictions on directory size (or transfer time) in the client.

Have you tried getting a directory listing using a standalone FTP application (console or GUI)?

With respect to the error - can you be more specific? Does it throw an exception or does it freeze? In either case, have a look at the log and see if there are any clues there. You could also post part of the log in your reply?

How many files are there in the directory?

- Hans (EDT Support)

Answer 2

Any information in the log file?

Calling Dir() in the past has been fine but this directory has grone to be VERY VERY large. It seems as though there's some type of timer the kills the Dir call after a certain amount of time.

I tried setting Timeout=0 on the Client but that did not solve the problem.

Any thoughts?

Thanks,
- Kevin

Answer 3

There are 25,900 files in the directory (yes that's a lot).

The Exception that is caught is as follows:

A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond

The DEBUG Log is as follows:

DEBUG [EnterpriseDT.Net.Ftp.FTPClient] 27 Nov 2005 09:43:57.656 : Connecting to <IP_WAS_HERE>:21
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 27 Nov 2005 09:43:57.765 : 220 Microsoft FTP Service
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 27 Nov 2005 09:43:57.765 : ---> USER <USER_WAS_HERE>
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 27 Nov 2005 09:43:57.828 : 331 Password required for <USER_WAS_HERE>.
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 27 Nov 2005 09:43:57.828 : ---> PASS ********
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 27 Nov 2005 09:43:57.906 : 230 User <USER_WAS_HERE> logged in.
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 27 Nov 2005 09:43:57.906 : ---> CWD /Uploads/files
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 27 Nov 2005 09:43:57.953 : 250 CWD command successful.
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 27 Nov 2005 09:43:57.953 : ---> TYPE I
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 27 Nov 2005 09:43:58.000 : 200 Type set to I.
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 27 Nov 2005 09:43:58.000 : ---> PASV
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 27 Nov 2005 09:43:58.046 : 227 Entering Passive Mode (<IP_INFO_WAS_HERE>).
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 27 Nov 2005 09:44:19.125 : ---> QUIT
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 27 Nov 2005 09:44:19.171 : 221

Any ideas?

Thanks,
- Kevin

Answer 4

I changed the mode to ACTIVE and it seems to be wotrking again.

First off, can anyone explain why a Dir() call in PASV mode would have worked in the past but would stop working? Does the Dir() call somehow get cached before being returned when it's in PASV mode?

Also, if anyone has any other ideas or things to watch out for let me know.

Thanks,
- Kevin

Answer 5

We don't know what's happening here - but 25,000+ files in a directory really shouldn't be! A maximum of 500 is more realistic - even the FTP server may have trouble reading that many depending on the OS.

I changed the mode to ACTIVE and it seems to be wotrking again.

First off, can anyone explain why a Dir() call in PASV mode would have worked in the past but would stop working? Does the Dir() call somehow get cached before being returned when it's in PASV mode?

Also, if anyone has any other ideas or things to watch out for let me know.

Thanks,
- Kevin