Windows如何创build一个新的文件名？

这将是一个愚蠢的问题：

如果我右键单击并创build一个文件，它会给出一个默认名称，如New file 。

然后我只是做同样的事情来创build另一个文件，它也会给该文件一个默认名称。 由于名称已被使用，所以它将被命名为New file(2) 。

在这里我有三个文件命名为：

如何解密Windows 8转储

什么是Windows 2008服务器启动文件夹的path

如何检测显示器是否处于待机模式？

Chrome浏览器JavaScript和原生Windows代码之间的通信

移动默认的AVDconfiguration文件夹（.android）

新文件

新文件（2）

新文件（3）

我删除New file(2)并创build一个新文件，名称将是New file(2)而不是New file(4)或其他。 所以我认为Windows会检查默认文件名中使用的数字。

这里有一个问题：如果我有1,000,000个文件全部使用默认文件名，最后一个是New file(1000000) ？ 如果是的话，剂量的number有限制？ 如果没有，这个number使用了什么数据结构，我的意思是如果数字是int32 ，当最后一个文件的名字数字等于int32最大数字时将使用什么？

感谢大家阅读我奇怪的问题。

TeamCity GitHub私钥访问被拒绝

如何使用Go翻转文件的Windows存档位

在Windows 10 Build版本10074上启用开发人员模式

赢10：需要什么registry键项来注册我的应用程序的电话协议

禁用Ctrl + Alt + Delete不修改GINA？

用于生成文件名的函数是PathMakeUniqueName() 。 对新文件名的唯一限制是它不能超过文件名所允许的最大长度，所以不能自动假定这个数字必须在系统字大小之内。

话虽如此，但有理由相信这实际上仅限于系统字的大小，尽管据我所知，没有人真正测试过这个字。

我刚刚尝试了这个1000，并删除了文件500，它创建的文件500不是1001.从编程的角度思考这个问题，如果你想到操作系统：

在32位操作系统中，我会想象这个数字是从一个Int32构建的。 在一个64位的操作系统中，可能会使用Int64，但是如果int中的默认数据结构是Int32，而不管x32或者x64是什么，我会这样说最大的文件数量将是Int32.MaxValue或2,147,483,647

现在给出了这样做的方式，可能会读取存在于起始名称的文件并分割文件编号。

想想这样，如果你有1,000个文件全部命名为New Text Document – copy（＃）.txt，那么操作系统会做类似下面的伪代码：

public string GetNextFileName(string direcctoryPath) { var files = Directory.GetFiles(directoryPath); var copies = files.Where(x => x.Name.StartsWith("New Text Document - copy")); var countOfcopies = files.Count(); //Inefficient way to do this but demonstrates what it is: var numbers = copies.Select(x => x.Name.SubString(x.Name.IndexOf("("),x.Name.IndexOf(")").GetTheOffsetStringLength()).Select(x => Int32.Parse(x)); var nextIndex = countOfcopies + 1; for(var i = 1; i <= countOfcopies; i++){ if(numbers[i-1] > i) { nextIndex = i; break; } } return "New Text Document - copy (" + nextIndex + ").txt"; }

所以每个新的副本将获得第一个可用的索引。 操作系统正在做一些优化，但根本的概念必须是这样的。 因此，考虑到上面的假设，最大的“默认名称”将是Int32.MaxValue和性能会退化，但总体而言不是太多。 O（n）甚至Int32.MaxValue并不可怕。 计算机擅长计算事物。

由于Windows是专有软件，除了微软员工之外没有人知道真正的答案，我们所能做的就是猜测。

一个32位整数似乎是一个很好的猜测（到处都是非常标准的数据类型）。 64位版本也可以轻松使用64位整数。 如果实际情况是这样，则实际限制是计数变量的最大值。

在此之上，许多时髦的事情发生了。 如果资源管理器检查溢出，那么它可能会显示“太多的文件”的错误或类似的情况下最好的情况下，或者它可能只是一个异常崩溃。 但是如果没有检查溢出，计数器将重新开始。 签名变量会产生负数！ 甚至更有趣的情况是，当它再次达到零时，可能产生无限循环，一遍又一遍地检查已经检查过的文件的存在。 从用户的角度来看，这几乎等同于崩溃。

对字符串进行操作来获取数字也是可能的（但是不太可能），并且会将文件系统支持的文件名的最大长度增加到最大值。 在那里，会发生类似的崩溃或错误。

无论如何，任何人检查这些限制似乎都是不可能的，因为它们很容易超出文件名生成的正常使用情况。 此外，检查这么多文件的存在将花费大量的时间。 我怀疑微软的任何人都不屑检查这个，或者他们只是做了一些小的修复来防止漏洞。 但是，再次，这只是我们可以做的猜测。