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

StackOverflow https://stackoverflow.com/questions/833291

  •  08-07-2019
  •  | 
  •  

题

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

在 Win32 上，有 MAX_PATH 定义。Unix/linux 的等价物是什么？

有帮助吗？

解决方案

有一个 PATH_MAX, ，但是有点问题。来自错误部分 真实路径(3) 手册页：

POSIX.1-2001此功能的标准版本通过设计破坏，因为无法确定适合输出缓冲区的尺寸， 解析路径. 。根据 POSIX.1-2001，缓冲 大小 最大路径 就足够了，但是 最大路径 不需要是定义的 常量，并且可能必须使用 路径配置(3). 。和 问 路径配置(3) 并没有真正的帮助，因为一方面 POSIX警告说，结果 路径配置(3) 可能很大，而且 另一方面，不适合恶意分配内存 路径配置(3) 可能会返回 -1 来表示 最大路径莫 界。

其他提示

到目前为止，关于* nix方面的其他答案似乎都是正确的，但我会在Windows上添加关于它的警告。

你被文件欺骗（遗漏）。

确实定义了

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

添加一个事实，即路径名实际上是Unicode（嗯，UTS-16），而当<！>“ANSI <！>”时; API用于转换内部Unicode名称和从内部Unicode名称转换依赖于包括当前代码页在内的一系列因素，并且您有混淆的秘诀。

有关Windows规则的详细说明，请访问 MSDN 。这些规则比我在这里总结的要复杂得多。

编辑：由于KitsuneYMG的评论，我在上面将\更改为\\?\UNC\server\share\。

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

没有任何前缀的路径在最广泛的Windows平台上兼容。如果它被限制为7位ASCII字符，那么它与版本2.0左右的16位DOS兼容（每当引入子目录时，实际上可能已经在DOS 3中;但是DOS 1.0只有根目录和< =>字符没有特殊意义）。

\\server\share\前缀会导致路径名的余额逐字传递给相应的文件系统驱动程序，这会产生将限制放到\\.\COM50字符的效果。如果长路径名也在网络共享上，则可以使用扩展的UNC名称，前缀为<=>而不是正常的UNC名称<=>。使用此前缀限制了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 不是一个特殊名称，如COM1。

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

好吧，至少在 Linux 上，有：

  • PATH_MAX （定义于 limits.h)

  • FILENAME_MAX （定义于 stdio.h)

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

更新： : glibc 手册中的一些信息

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

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

<！>“;与PATH_MAX不同，即使没有施加实际限制，也会定义此宏。在这种情况下，其值通常是非常大的数值。在GNU系统上总是这样。

使用备注：不要将FILENAME_MAX用作存储文件名的数组的大小！你不可能制造出那么大的阵列！使用动态分配。<！>“

您可以使用pathconf()在运行时计算出来，但<limits.h>中还有一个PATH_MAX预处理器定义。

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

realpath() 扩展所有符号链接并解析对路径命名的空终止字符串中的 /./、/../ 和额外“/”字符的引用，以生成规范化的绝对​​路径名。生成的路径名作为空终止字符串存储在resolved_pa​​th 指向的缓冲区中，最多可达 PATH_MAX 字节。生成的路径将没有符号链接、/./ 或 /../ 组件。

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

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

limits.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
许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top