在 linux/unix 下是否有与 WinAPI 的 MAX_PATH 等效的东西？

问题描述：

如果我想分配一个字符数组（在 C 中），保证其足够大以容纳任何有效的绝对路径+文件名，那么它需要多大。

在 Win32 上，有 MAX_PATH 定义。Unix/linux 上的对应定义是什么？

解决方案 1：

有一个PATH_MAX，但是有点问题。从realpath(3)手册页的 bug 部分来看：

此函数的 POSIX.1-2001 标准版本在设计上存在缺陷，因为无法确定输出缓冲区solved_pa​​th的合适大小。根据 POSIX.1-2001，大小为PATH_MAX的缓冲区就足够了，但PATH_MAX不必是定义的常量，可能必须使用pathconf(3)来获取。而且询问pathconf(3)并没有真正的帮助，因为一方面 POSIX 警告pathconf(3)的结果可能很大，不适合 mallocing 内存，另一方面
pathconf(3)可能会返回 -1 以表示PATH_MAX没有界限。

解决方案 2：

到目前为止，其他答案似乎都正确地指出了 *nix 方面的问题，但我将在 Windows 上添加有关它的警告。

你被文档（由于遗漏）欺骗了。

MAX_PATH确实有定义，甚至可能适用于存储在 FAT 或 FAT32 上的文件。但是，任何路径名都可以以 为前缀，以\?告诉 Windows API 忽略MAX_PATH并让文件系统驱动程序自行决定。此后，定义变得模糊。

除此之外，路径名实际上是 Unicode（嗯，UTS-16），并且当使用“ANSI”API 时，内部 Unicode 名称的转换取决于包括当前代码页在内的一系列因素，因此您很容易感到困惑。

MSDN上有关于 Windows 规则的详细描述。这些规则比我在这里总结的要复杂得多。

编辑：感谢 KitsuneYMG 的评论，我在上面进行\.了更改。\?

Windows 路径和命名空间非常复杂。有些人甚至认为它们太复杂了。复杂性的一个来源是 Win32（现在是 Win64）API 是位于 Windows NT 本机系统之上的子系统。

没有任何前缀的路径在大多数 Windows 平台上都兼容。如果它被限制为 7 位 ASCII 字符，那么它与 2.0 版左右的 16 位 DOS 兼容（每当引入子目录时，这实际上可能是在 DOS 3 中；但 DOS 1.0 只有根目录，并且该``字符没有特殊含义）。

前缀\?使得路径名的余额被逐字地传递给相应的文件系统驱动程序，这产生了放弃MAX_PATH字符限制的效果。如果长路径名也在网络共享上，那么您可以使用带前缀的扩展 UNC 名称\?UNCservershare代替普通 UNC 名称\servershare。使用此前缀会限制可移植性到 Win32 和更高版本的 Windows 平台，但除非您需要在旧硬件上支持 16 位 Windows，否则这不是什么大问题。

前缀\.则不同。它允许访问 Windows 自动将特殊命名的设备集作为特殊文件名映射到每个文件夹中的设备对象。这些特殊名称包括 CON、PRN、AUX、NUL、COM1、COM2、COM3、COM4、COM5、COM6、COM7、COM8、COM9、LPT1、LPT2、LPT3、LPT4、LPT5、LPT6、LPT7、LPT8 和 LPT9。请注意，无论是否使用扩展名，或大小写混合，所有这些名称都是特殊的。但您可能安装了 10 个或更多 COM 端口。如果您使用 USB 调制解调器或 USB 串行端口适配器，这种情况很快就会发生，因为每个唯一的基于 USB 的串行端口都将被分配一个不同的 COMn 名称。如果您需要访问第 50 个串行端口，那么您只能使用该名称进行访问，\.COM50因为 COM50不像COM1 那样是一个特殊名称。

我上面引用的 MSDN 页面有正确的区分，我只是在原始答案中输入了错误的前缀。

解决方案 3：

嗯，至少在 Linux 上，有：

• PATH_MAX（定义于limits.h）

• FILENAME_MAX（定义于stdio.h）

4096这两项都在我的系统（x86 Linux）上设置。

更新：：来自glibc 手册的一些信息

仅当系统对相关参数具有固定、统一的限制时，以下每个宏才会在 limits.h 中定义。如果系统允许不同的文件系统或文件具有不同的限制，则宏未定义；使用 pathconf 或 fpathconf 找出适用于特定文件的限制

解决方案 4：

FILENAME_MAX 是 ISO C 标准的一部分，它适用于 UNIX 和 Windows。但是，GNU C 库文档包含以下警告：

“与 PATH_MAX 不同，即使没有施加实际限制，也会定义此宏。在这种情况下，它的值通常是一个非常大的数字。在 GNU 系统上总是如此。

使用注意事项：不要使用 FILENAME_MAX 作为存储文件名的数组的大小！你不可能把数组弄得那么大！使用动态分配。

解决方案 5：

您可以pathconf()在运行时使用它来弄清楚，但也有一个 PATH_MAX 预处理器定义<limits.h>。

解决方案 6：

您可以使用该realpath函数为特定路径分配足够大的缓冲区。如果您将空指针作为第二个参数传递给它，它将为该路径分配足够大的缓冲区。手册页可能比我解释得更好：

realpath() 扩展所有符号链接，并解析对 path 命名的以空字符结尾的字符串中 /./、/../ 和额外 '/' 字符的引用，以生成规范化的绝对​​路径名。生成的路径名以以空字符结尾的字符串形式存储在 solved_pa​​th 指向的缓冲区中，最多为 PATH_MAX 个字节。生成的路径将没有符号链接、/./ 或 /../ 组件。

如果将 solved_pa​​th 指定为 NULL，则 realpath() 使用 malloc(3) 分配最多 PATH_MAX 字节的缓冲区来保存解析的路径名，并返回指向此缓冲区的指针。调用者应使用 free(3) 释放此缓冲区。

http://linux.die.net/man/3/realpath

解决方案 7：

限制.h

/*
 * File system limits
 *
 * NOTE: Apparently the actual size of PATH_MAX is 260, but a space is
 *       required for the NUL. TODO: Test?
 * NOTE: PATH_MAX is the POSIX equivalent for Microsoft's MAX_PATH; the two
 *       are semantically identical, with a limit of 259 characters for the
 *       path name, plus one for a terminating NUL, for a total of 260.
 */
#define PATH_MAX    260

minwindef.h

#define MAX_PATH 260