Windows 内核中可能的最大文件名长度答案

【问题标题】：Maximum Possible File Name Length in Windows KernelWindows 内核中可能的最大文件名长度
【发布时间】：2011-06-05 04:11:39
【问题描述】：

我想知道，Windows 内核允许的最长可能的名称长度是多少？

例如：我知道内核使用UNICODE_STRING 结构来保存所有对象路径，并且由于宽字符串的字节长度存储在USHORT 中，因此允许最大路径长度为 2^15 - 1 个字符。对文件名（而不是路径）有类似的hard 限制吗？（我不在乎 NTFS 或 FAT32 是否施加了特定限制；我正在寻找内核中理论上允许的最长名称，假设没有额外的文件系统或 shell 限制。）

(编辑：对于那些想知道为什么这很重要的人，请考虑通常情况下，遍历目录是通过FindFirstFile/FindNextFile 调用实现的，每个文件调用一次。给定名为NtQueryDirectoryFile 的函数，它是底层系统调用并在每次调用时返回多个文件名，实际上可以利用路径上的最大长度限制来制作一个仅使用堆栈作为缓冲区的极快的目录遍历器。现在我正在尝试扩展这个概念，我需要知道文件名的最大大小。）

【问题讨论】：

当你说 USHORT 然后 2^31 时，你是什么意思？如果它是无符号的，那么它将是 2^32，但一个 ushort 最多只能存储 2^16（它是 16 位长）我是不是在某个地方误解了你的意思？
抱歉，打错了；我的意思是 2^15 - 1。我改了，谢谢。
而且我忘了考虑到每个字符需要 2 个字节的内存，将你获得的空间量减半......无论如何，我猜内核中的这样一个限制会被记录得很差并且从 XP 到 Vista/Win7 不等。希望有人可以帮助你，+1
您的方法是否足够快以产生任何有意义的差异？如果有一些内部限制，那么什么会阻止微软在未来改变它？据我所知，路径组件仅受底层文件系统的限制；我怀疑在可预见的将来它会超过 255（主要是为了向后兼容）。
是的，如果要读取的全部数据缓存在系统内存中，它会在不到四秒的时间内遍历我的整个 C: 驱动器（有 Windows 7，总共大约 400,000 个文件） .一旦我切换到使用 malloc() 而不是基于堆栈的内存，所花费的时间至少会翻倍——有时更多。而且我注意到它在搜索文件时可能比 Explorer 快一两个数量级。如果你有兴趣，我可以把代码贴在某个地方，尽管它是用 D 语言编写的。

标签： winapi path kernel filenames name-length

【解决方案1】：

路径的最大长度为 32,767 个字符，其中每个路径组件（目录或文件）的最大长度为 255 个字符（更准确地说，是 GetVolumeInformation 函数的 lpMaximumComponentLength 参数中返回的值）。

这是documented on MSDN。

【讨论】：

+1，谢谢你的链接，它很有用。但我正在寻找一个编译时的绝对最大值，页面上说 255“通常”是最大值。所以我的问题是，除了 32K 之外，还有什么绝对上限吗？
（抱歉，忘记给 +1 了；已修复。）:)
我想我会接受这个，因为我认为没有更好的答案。谢谢。 :)

【解决方案2】：

啊，我发现this page自己保证文件名不能超过 255 个字符：

路径名的长度不得超过 32,760 个字符。
...

每个路径名组件的长度不得超过 255 个字符。

这让我想知道：

为什么Windows use `ULONG`s for file name lengths，当它uses `USHORT`s for path lengths？！

如果有人知道这是为什么，请发表/评论！我比较好奇。 :)

【讨论】：

ULONG 可能用于保持与目录信息头记录中其他字段的对齐。 UNICODE_STRING 的 USHORT 限制是真正的限制。在信息标头中使用 USHORT 将需要填充值或使结构的其余部分不对齐。注意每条头记录需要8个字节对齐。

为什么Windows use ULONGs for file name lengths，当它uses USHORTs for path lengths？！

为什么Windows use `ULONG`s for file name lengths，当它uses `USHORT`s for path lengths？！