我现在正在编写一个文件系统。 statvfs（甚至是statfs）结构包含一个字段，指定该路径中名称的最大长度。由于PATH_MAX在pathconf联机帮助页（getconf）中定义，这意味着它是基于每个目录定义的（因此，由底层文件系统确定）。如何指定此值？
由于这个问题被标记为“FUSE”......
我在处理FUSE文件系统时遇到了这个问题。我给FUSE开发者写了一封电子邮件，寻求澄清。当前libfuse维护者的回复（2018年1月）：无法在FUSE文件系统[驱动程序]中指定最大路径长度。
有没有办法让FUSE文件系统通知在其上运行的软件有关正确的最大路径长度？
不是现在，不。
如果没有，应该有吗？
可能是。补丁欢迎:-)
PATH_MAX主要表现为文件系统函数调用接口的属性，所以我认为让它在各个目录之间变化是不合理的。
例如，重命名或移动其中包含大型目录树的目录可能会使最长的绝对路径名更长，并且限制它将是复杂且低效的。
相反，PATH_MAX用于允许内核将传递的路径名复制到临时未分页的内存，然后可以在不需要在每次访问时允许页面错误的情况下对其进行处理。分配大量此类内存可能会阻止内核正在执行的大多数其他操作，甚至会导致内核崩溃。
在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，它应该返回通常的编译时常量。但是，在我的测试中，它似乎正在捕获另一个NOOP函数，它返回一个ENXIO并且我无法使pathconf工作。
额外奖励：对于NAME_MAX，implement statfs and set f_namemax.
POSIX允许_PC_PATH_MAX根据当前目录而变化，但这并不意味着不改变它的系统不兼容。
PATH_MAX存在的真正原因是内核在使用它进行任何实际工作之前将路径名复制到内核空间中。
你断言在PATH_MAX中有一个与statvfs相关的领域是错误的。这与NAME_MAX有关，这是另一回事。
关于其他操作系统，我还不够，但至少在FreeBSD 5.2.1中这是一个系统范围的设置
PATH_MAX位于＃62 sys/syslimits.h
因为返回UFS FS的static int ufs_pathconf()信息的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 */
}
PATH_MAX是系统范围的设置，通常在pathmax.h中定义为：
define PATH_MAX (pathconf ("/", _PC_PATH_MAX) < 1 ? 1024 \
: pathconf ("/", _PC_PATH_MAX))