我们正在使用Windows 2008（EC2），并有一个应用程序存储大量的子文件夹在一个特定的文件夹（即根/子文件夹1，根/子文件夹2，根/子文件夹3等）
我们预计有数以千万计的子文件夹和可扩展性问题出现。 你有什么想法，如果Windows 2008将能够处理这个？ 性能如何，是否有一个魔术线，之后的任何文件夹操作（如创build新的子文件夹，或查找现有）会大大减慢？ 有没有硬数字？
作为替代scheme，我们正在考虑将这个扁平结构转换成一棵树
root/subfolder1_/subfolder1 root/subfolder1_/subfolder11 ... root/subfolder2_/subfolder2 你对此有何看法？
这将很大程度上取决于磁盘子系统。 在共享的虚拟机主机（如EC2）上，这将很难预测，因为使用将是dynamic的。
我可以build议的最好的想法是尝试一下，看看会发生什么。 编写batch file或PowerShell脚本来创build文件夹并测量所花费的时间。 看到新的项目 ，看到这篇文章/代码开始做一个计时器。 一旦你完成了，你应该能够很好地感受到它将如何处理。
有帮助吗？： http : //msdn.microsoft.com/en-us/library/aa365247.aspx
“Windows API有许多函数也有Unicode版本，允许一个最大总长为32,767个字符的扩展path。”