2

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，甚至是一些实用程序库？有问题的代码不需要打开文件描述符的路径，它只需要当前可以找到文件描述符的一些规范路径（这是为了处理跟踪提议的 Boost.AFIO的第三方文件重命名）。

我提前感谢您的帮助。FreeBSD 是该功能的主要操作系统中唯一引人注目的，没有它，编写文件系统竞争安全检测代码是不可能的:(

编辑：我在http://comments.gmane.org/gmane.os.solaris.opensolaris.zfs/38277找到了关于让 ZFS 将 inode 转换为路径的讨论。显然有一个 ZFS_IOC_OBJ_TO_PATH ioctl，但从谷歌判断这不是一个很好的代码路径

4

1 回答 1

0

事实证明，KERN_PROC_FILEDESC 不起作用的事实实际上是 FreeBSD 内核中的一个错误。我已经在https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197695记录了它。

KERN_PROC_FILEDESC 确实适用于目录文件描述符，包括跟踪重命名和删除。它不完美地适用于常规文件描述符，有时会返回一个路径，然后突然返回一个空路径，然后再随机返回一个路径。我认为在 10.x 版本中的某个地方出现了问题 :(

希望能帮助其他同样陷入困境的人。

于 2015-02-28T04:26:10.633 回答