在使用 FS 时,我发现 PATH_MAX 宏实际上不起作用,即目录的完整路径不适合 PATH_MAX 大小的缓冲区。
我决定使用脚本来确定绝对路径的最大可能长度,我得到了 ~130791(这大约是我系统上的 PATH_MAX 的 32 倍)字符,然后 shell shell dash 停止运行任何程序并创建目录变得不可能,但显然这只是外壳本身的问题,没有限制。
如果实际上似乎没有限制,我想知道为什么需要这个宏?
在使用 FS 时,我发现 PATH_MAX 宏实际上不起作用,即目录的完整路径不适合 PATH_MAX 大小的缓冲区。
我决定使用脚本来确定绝对路径的最大可能长度,我得到了 ~130791(这大约是我系统上的 PATH_MAX 的 32 倍)字符,然后 shell shell dash 停止运行任何程序并创建目录变得不可能,但显然这只是外壳本身的问题,没有限制。
如果实际上似乎没有限制,我想知道为什么需要这个宏?
PATH_MAX
是可以传递给系统调用的路径(绝对或相对)的最大长度,例如,如果路径较长,open()
它将拒绝打开文件并设置errno
为。ENAMETOOLONG
这是因为内核将参数复制到它的地址空间中,为了避免滥用它,有必要限制参数的大小。处理更长的路径完全落在程序员的肩上。例如,要打开一个类似的文件,您可以执行一项或多项操作
chdir()
,然后open()
使用相对路径,或者使用openat()
.与误解相反,
PATH_MAX
从来没有(可能历史学家纠正我)系统中可以存在的绝对路径的最大长度,也没有任何特定的 FS。由于 *nix 文件系统的层次结构和多样性的性质,根本不能施加这样的限制。此外,还有几个库函数仍然依赖于
PATH_MAX
. 最显着的例子是realpath()
。