首先我问的是：ftp directory listing timeout. Huge number of subdirs。我得到了答案。
仍然因为我可以在目录中拥有数十万个 FTP 对象，所以扫描它可能需要很长时间。但是我认为有可能检索所有以'A'开头然后是'B'等等的对象......当它检索目录时，它可以开始在另一个线程上处理它们而无需等到它获得整个列表.
是否可以使用标准FtpWebRequest 使用通配符进行 FTP 目录列表？
【问题讨论】：
标签： c# ftp wildcard ftpwebrequest
FTP specification (RFC 3659) 的最新更新明确禁止它。来自section 2.2.2 of that specification, titled "Wildcarding"（强调我的）：
对于本规范中定义的命令，所有路径名都是 从字面上看。也就是说，对于作为参数给出的路径名 一个命令，其名称与给定路径名相同的文件是 默示。路径名中的任何字符都不能被视为特殊字符或 “魔术”，因此没有模式匹配（除了完全相等） 在给定的路径名和 NVFS 中存在的文件之间 允许服务器-FTP。
需要某种形式的模式的客户 匹配功能必须获得相关的列表 目录，或目录，并实现自己的文件名 选择程序。
也就是说，如果您的服务器支持它，您仍然可以使用FtpWebRequest class，但您必须自己处理响应以处理项目列表，因为 .NET 类无法理解您的服务器-特定的扩展。
【讨论】：
FTP 规范说文件列表命令（LIST、NLIST、MLSD 等）的参数是路径名。所以无论如何都不应该有通配符。
RFC 959 (LIST + NLIST)：
2.2.术语
...
pathname路径名被定义为字符串，必须是 用户输入文件系统以识别文件。 路径名通常包含设备和/或目录名称，并且 文件名规范。 FTP 尚未指定标准 路径名约定。每个用户必须遵循文件命名 传输中涉及的文件系统的约定。
...
5.3.1。 FTP 命令
...
LIST [<SP> <pathname>] <CRLF>NLST [<SP> <pathname>] <CRLF>
RFC 3659(MLSD)：
2.2.2.通配符
对于本规范中定义的命令，所有路径名都是 从字面上看。也就是说，对于作为参数给出的路径名 对于命令，其名称与给定路径名相同的文件 是暗示的。路径名中的任何字符都不能被视为 特殊或“魔术”，因此没有模式匹配（除了精确 相等）给定的路径名和文件中存在的文件 服务器-FTP的NVFS是允许的。
...
7.1。 MLSx 请求的格式
...
MLSx 命令的语法是：
mlst = "MLst" [ SP pathname ] CRLF mlsd = "MLsD" [ SP pathname ] CRLF
实际上，尽管许多 FTP 服务器确实支持参数中的通配符。但由于规范不允许这样做，显然没有为支持的通配符设定标准。
vsftpd 支持*、? 和{} 以及LIST。 vsftpd 不支持现代的MLSD。
proftpd 支持*、? 和[]。但仅限LIST。它明确不允许带有现代 MLSD 的通配符和注释：
RFC3659 明确不支持全局字符。所以警告 这个，但让命令按原样继续。
pureftpd 支持*、? 和[] 用于LIST 和MLSD。
FileZilla 服务器仅支持 * 和 LIST 和 MLSD。
但一般来说，您根本不应该依赖 FTP 服务器来支持任何通配符。
唯一可靠的方法是检索完整的目录列表并在本地过滤文件。例如，您可以使用正则表达式（Regex class）
【讨论】：