Windows(NtQueryObject),Linux(/ proc / self / fd / x)和 OS X(F_GETPATH)都有用于检索当前打开的文件描述符的路径的方法。FreeBSD 通过类似以下代码的东西:
size_t len;
int mib[4]={CTL_KERN, KERN_PROC, KERN_PROC_FILEDESC, getpid()};
BOOST_AFIO_ERRHOS(sysctl(mib, 4, NULL, &len, NULL, 0));
std::vector<char> buffer(len*2);
BOOST_AFIO_ERRHOS(sysctl(mib, 4, buffer.data(), &len, NULL, 0));
for(char *p=buffer.data(); p<buffer.data()+len;)
{
struct kinfo_file *kif=(struct kinfo_file *) p;
if(kif->kf_fd==fd)
{
lock_guard<pathlock_t> g(pathlock);
_path=path::string_type(kif->kf_path);
return _path;
}
p+=kif->kf_structsize;
}
这令人恼火地适用于几乎所有类型的文件描述符除了返回一个空路径的常规文件,至少在 FreeBSD 10 中,我认为这是一个监督,因为从检查内核代码似乎微不足道返回路径,尽管可能有性能原因不这样做。
procstat 使用与上述相同的 API,因此也只返回除常规文件以外的所有内容的路径。使用 statfs()我至少可以获取文件的挂载点的路径,但是检索挂载点和实际文件之间的路径片段是问题所在。
因此,让我问这个问题:是否有可能要求 UFS 或 ZFS 从 inode 返回路径片段,也许使用一些魔术 ioctl 或 sysctl,甚至一些实用程序库?有问题的代码不需要打开文件描述符的路径,它只需要一些规范路径文件描述符当前可以在0。
我提前感谢任何帮助。FreeBSD 是这个功能的主要操作系统中唯一的展示者,如果没有它,就不可能编写文件系统竞赛安全检测代码:(
编辑:我发现了一个关于让 ZFS 将 inode 转换为http://comments.gmane.org/gmane.os.solaris.opensolaris.zfs/38277的路径的讨论。显然有一个 ZFS_IOC_OBJ_TO_PATH ioctl,但这不是一个很好的代码路径,从谷歌判断
事实证明,KERN_PROC_FILEDESC 不起作用的事实实际上是 FreeBSD 内核中的一个错误。我已经在https://bugs.freebsd.org/bugzilla/sw_bug.cgi?id=197695记录了它。
KERN_PROC_FILEDESC 确实可以完美地用于目录文件描述符,包括跟踪重命名和删除。它不完全适用于常规文件描述符,有时返回一个路径,然后相当突然地返回一个空路径,然后随机稍后再次返回一个路径。我认为在 10.x 版本中的某个地方有些东西在某个地方被了:(
希望能帮助其他人同样卡住。
本站系公益性非盈利分享网址,本文来自用户投稿,不代表边看边学立场,如若转载,请注明出处
评论列表(10条)