我目前正在编写一个文件系统。 statvfs（甚至statfs）结构包含一个字段，指定该路径中名称的最大长度。由于PATH_MAX 在pathconf 手册页（getconf）中定义，这意味着它是在每个目录的基础上定义的（因此，由底层文件系统确定）。如何指定这个值？
【问题讨论】：
标签： unix filesystems posix fuse
PATH_MAX 是系统范围的设置，通常在 pathmax.h 中定义为：
define PATH_MAX (pathconf ("/", _PC_PATH_MAX) < 1 ? 1024 \
: pathconf ("/", _PC_PATH_MAX))
【讨论】：
sort 命令行实用程序的一部分，不是内核或标准 C 库的一部分。
PATH_MAX 主要表现为文件系统函数调用接口的属性，所以我认为让它在不同目录之间变化没有多大意义。
例如，重命名或移动其中包含大型目录树的目录可能会使最长的绝对路径名变长，并且限制它会很复杂且效率低下。
相反，PATH_MAX 用于允许内核将传递的路径名复制到临时未分页内存中，然后可以对其进行处理，而无需在每次访问时允许页面错误。分配大量此类内存可能会阻塞内核正在执行的大多数其他操作，甚至导致内核崩溃。
【讨论】：
pathconf() 函数可以根据你传递给它的文件名返回不同的值，这意味着它可能会根据它所代表的文件系统而有所不同目录。但是，POSIX 也确实说：返回的值不应比应用程序使用实现的 <limits.h> 或 <unistd.h> 编译时可用的相应值更具限制性。
{PATH_MAX} 值用于用户模式文件系统实现（不是熔断器，而是 open() 解释同一地址空间中的名称）。即便如此，应用程序也不能使用不同的值来避免竞争（如果他们为每个组件都调用pathconf() 的麻烦）。此外，当{PATH_MAX} 不是常量时，使用非空缓冲区指针调用realpath() 之类的某些事情会变得未定义，但这并不否认实现接受更长的路径名。
我对其他操作系统做得不够，但恕我直言，这是至少在 FreeBSD 5.2.1 中的系统范围设置
PATH_MAX 位于#62 sys/syslimits.h
因为 static int ufs_pathconf() 返回 UFS FS 的 PATHCONF 信息，所以以您指定的方式使用此变量。
/*
* Return POSIX pathconf information applicable to ufs filesystems.
*/
int
ufs_pathconf(ap)
struct vop_pathconf_args /* {
struct vnode *a_vp;
int a_name;
int *a_retval;
} */ *ap;
{
switch (ap->a_name) {
.
.
.
.
case _PC_PATH_MAX:
*ap->a_retval = PATH_MAX;
return (0);
.
.
.
.
default:
return (EINVAL);
}
/* NOTREACHED */
}
【讨论】：
在 Linux 上，glibc 的 pathconf 实现返回编译时常量值 PATH_MAX，因此没有运行时魔法 FUSE 或任何其他人都可以执行调整它。 （请参阅 sysdeps/unix/sysv/linux/pathconf.c，它属于 sysdeps/posix/pathconf.c。）您的问题“如何指定我的文件系统的 PATH_MAX？”的答案。是“你不能。glibc 不允许你，FUSE 只是信使。”
最终结果是一个棘手的情况。 Here's a blog post that discusses the code that does and does not care about PATH_MAX. 依赖路径不超过 PATH_MAX 的软件很久以前就被其他文件系统破坏了，因此您可以安全地忽略 PATH_MAX。
在 MacOS X（可能还有其他 BSD）上：pathconf 的实现完全在内核中，并且可以在每个文件系统中换出。 OSXFUSE 包含一个 NOOP 版本的 pathconf，它应该返回通常的编译时常量。但是，在我的测试中，它似乎正在捕获另一个返回 ENXIO 的 NOOP 函数，我无法让 pathconf 工作。
奖励：对于 NAME_MAX，implement statfs and set f_namemax.
【讨论】：
POSIX 允许 _PC_PATH_MAX 根据当前目录变化，但这并不意味着 不 变化的系统不兼容。
PATH_MAX 存在的真正原因是内核在对其进行任何实际操作之前将路径名复制到内核空间中。
您断言statvfs 中存在与PATH_MAX 相关的字段是错误的。这与NAME_MAX 有关，这是另一回事。
【讨论】：
由于这个问题被标记为“FUSE”......
我在处理 FUSE 文件系统时遇到了这个问题。我给 FUSE 开发人员写了一封电子邮件，寻求澄清。当前libfuse维护者的回复（2018 年 1 月）：没有办法指定 FUSE 文件系统 [驱动程序] 中的最大路径长度。
FUSE 文件系统有没有办法通知在上面运行的软件 关于正确的最大路径长度？
暂时没有，没有。
如果没有，应该有吗？
可能是的。欢迎补丁:-)
【讨论】：