文件路径长度有多重要？答案

【问题标题】：How important is file path length?文件路径长度有多重要？
【发布时间】：2011-08-19 08:34:49
【问题描述】：

我正在开发跨平台库，该库将用于在光学媒体上进行文件操作（创建、重命名、删除...）。所以我有与路径处理有关的问题。

目前我对库中的路径长度没有限制，因此用户可以创建操作系统不支持的路径很长的文件夹。例如，在 Windows 中，用户可以创建 pathlen 大于 MAX_PATH 字符的文件夹。那么在这种情况下我必须做什么呢？
第一个问题的解决方案，可能检查将在文件/文件夹复制后创建的新路径 len。但是还有一个问题，是windows和linux中MAX_PATH和PATH_MAX的取值不同造成的。

【问题讨论】：

【解决方案1】：

C 定义了一个标准宏FILENAME_MAX。

"这个宏常量展开成一个与所需大小对应的整数表达式用于 char 元素数组以保存允许的最长文件名字符串系统。或者，如果系统没有施加此类限制，则将其设置为推荐的用于保存任何文件名的字符数组的大小。"

这应该足够大，以指定一个字符串，该字符串包含可用于文件名的最长名称。它是一个宏，因此它的值取决于平台。

大多数OS APIS应该返回一个特定的错误，表明名称太处理，你可以正确处理它并报告给用户。

【讨论】：

在用户将文件复制到某个目标文件夹的情况下，检测路径长度是否正常是没有问题的。但是在文件夹的情况下呢？因为文件夹的路径本身可以适应长度限制，但是这个文件夹的子文件夹呢？在这种情况下我必须做什么。在开始复制之前，我必须检查文件夹的所有子文件夹的路径长度是否正确？
我认为这取决于您的需求。如果您想确保原子复制，即如果任何文件名太长，则不会将单个文件复制到目标文件夹，那么您需要递归预扫描要复制的文件，如果none 超过最大名称长度。否则，您可以一一检查并复制它们；）
感谢您的回答，我必须考虑一下）
current draft 中的措辞更清楚一些：“[...] 一个足够大的 char 数组所需的大小，以容纳实现保证可以打开的最长文件名字符串”——所以可能存在操作系统支持的文件名，但实现（即 C 库）不支持。事实上，在标准 C 函数不支持 Unicode 文件名的情况下，MSVC 一直都是这种情况。