我目前正在编写一个文件系统。(statvfs
甚至statfs
)结构包含一个字段,指定该路径中名称的最大长度。正如手册页 ( )PATH_MAX
中定义的那样,这意味着它是在每个目录的基础上定义的(因此,由底层文件系统确定)。如何指定这个值?pathconf
getconf
6 回答
PATH_MAX
主要表现为文件系统函数调用接口的属性,所以我认为让它在目录之间变化没有多大意义。
例如,重命名或移动其中包含大型目录树的目录可能会使最长的绝对路径名更长,并且限制它会很复杂且效率低下。
相反,PATH_MAX
它允许内核将传递的路径名复制到临时未分页的内存中,然后可以对其进行处理,而无需在每次访问时允许页面错误。分配大量此类内存可能会阻塞内核正在执行的大多数其他操作,甚至导致内核崩溃。
在 Linux 上,glibc 的实现pathconf
返回 PATH_MAX 的编译时常量值,因此没有运行时魔法 FUSE 或其他任何人都可以执行来调整它。(请参阅 sysdeps/unix/sysv/linux/pathconf.c,它属于 sysdeps/posix/pathconf.c。)您的问题“如何指定我的文件系统的 PATH_MAX?”的答案。是“你不能。glibc 不允许你,FUSE 只是信使。”
最终结果是一个棘手的情况。 这是一篇博客文章,讨论了关心和不关心 PATH_MAX 的代码。 依赖路径不超过 PATH_MAX 的软件很久以前就被其他文件系统破坏了,因此您可以安全地忽略 PATH_MAX。
在 MacOS X(可能还有其他 BSD)上: 的实现pathconf
完全在内核中,并且可以在每个文件系统中换出。OSXFUSE 包含一个 NOOP 版本的 pathconf,它应该返回通常的编译时常量。但是,在我的测试中,它似乎正在捕获另一个返回 ENXIO 的 NOOP 函数,我无法让 pathconf 工作。
奖励:对于 NAME_MAX,实现 statfs 并设置 f_namemax。
POSIX 允许_PC_PATH_MAX
根据当前目录进行更改,但这并不意味着不更改它的系统不兼容。
存在的真正原因PATH_MAX
是内核在对其进行任何实际工作之前将路径名复制到内核空间中。
您断言 in 中有一个PATH_MAX
-related 字段statvfs
是错误的。这与 相关NAME_MAX
,这是另一回事。
由于这个问题被标记为“FUSE”......
我在处理 FUSE 文件系统时遇到了这个问题。我给 FUSE 开发人员写了一封电子邮件,寻求澄清。当前维护者的回复libfuse
(2018 年 1 月):没有办法指定 FUSE 文件系统 [驱动程序] 中的最大路径长度。
FUSE 文件系统有没有办法通知在其上运行的软件正确的最大路径长度?
暂时没有,没有。
如果没有,应该有吗?
可能是。欢迎补丁:-)
供参考:完整的电子邮件线程
我对其他操作系统做得不够,但恕我直言,这是至少 FreeBSD 5.2.1 中的系统范围设置
PATH_MAX 在 #62 中找到sys/syslimits.h
因为static int ufs_pathconf()
which 返回PATHCONF
UFS FS 的信息,所以以您指定的方式使用此变量。
/*
* 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))