请记住，在Linux上，如果目录中有太多文件，shell可能无法展开通配符。我在Linux上托管的相册有这个问题。它将所有调整大小的图像存储在一个目录中。虽然文件系统可以处理许多文件，但shell不能。例子:

-shell-3.00$ ls A*
-shell: /bin/ls: Argument list too long

or

-shell-3.00$ chmod 644 *jpg
-shell: /bin/chmod: Argument list too long

≈13.5万份

NTFS | Windows 2012 server | 64bit | 4tb HDD | VBS

问题:当[单个]特定文件夹聚集了大约135,000个文件时，会出现灾难性的硬件问题。

“灾难性”= CPU过热，计算机关闭，更换硬件需要 "Specific Folder" =有一个VBS文件，用于将文件移动到子文件夹中 访问=该文件夹被多个客户端计算机自动访问/执行

基本上，我有一个位于文件服务器上的定制脚本。当自动化过程出现问题时(例如，文件溢出+大坝)，那么特定的文件夹会被淹没[未移动的文件]。当客户端计算机继续执行脚本时，灾难就形成了。文件服务器最终读取了135,000多个文件;每天这样做几百次。这种工作过载最终导致我的CPU过热(92°C等);结果导致我的机器崩溃。

解决方案:确保您的文件组织脚本永远不必处理包含135,000多个文件的文件夹。

我记得我运行了一个程序，它在输出时创建了大量的文件。每个目录按30000个文件进行排序。当我不得不重用产生的输出时，我不记得有任何读取问题。它是在一台32位的Ubuntu Linux笔记本电脑上，甚至Nautilus也显示了目录内容，尽管要等几秒钟。

ext3文件系统:类似的代码在64位系统上处理每个目录64000个文件。

这在一定程度上取决于Linux服务器上使用的特定文件系统。现在默认是ext3和dir_index，这使得搜索大目录非常快。

所以速度不应该是一个问题，除了你已经注意到的问题，那就是上市需要更长的时间。

一个目录下的文件总数是有限制的。我记得它可以运行到32000个文件。

没有一个数字是“太多”的，只要它不超过操作系统的限制。然而，不管哪种操作系统，一个目录中的文件越多，访问任何单个文件所需的时间就越长，而且在大多数操作系统上，性能是非线性的，因此从10,000个文件中找到一个文件所需的时间是在1,000个文件中找到一个文件所需的时间的10倍以上。

与目录中有大量文件相关的次要问题包括通配符展开失败。为了降低风险，您可以考虑根据上传日期或其他有用的元数据对目录进行排序。

我也遇到过类似的问题。我试图访问一个有一万多个文件的目录。构建文件列表和在任何文件上运行任何类型的命令花费的时间太长了。

我想了一个小php脚本来为自己做这件事，并试图找出一种方法来防止它在浏览器中超时。

下面是我编写的php脚本来解决这个问题。

列出FTP目录中文件太多的文件

如何帮助别人