name_to_handle_at（）的逻辑

Question

我没有得到关于新系统调用name_to_handle_at（）和open_to_handle_at（）的更多信息。有人可以帮我从这里出去吗。

谢谢

编辑。我只是有这个

http://comments.gmane.org/gmane.linux.man/2158

Answer 1

我会倾向于认为需要这些功能，支持部分或全部加入到2008年POSIX的*at()功能，如openat()：

#include <fcntl.h> 

int openat(int fd, const char *path, int oflag, ...); 

openat()函数应该等同于open()函数，除非路径指定相对路径。在这种情况下，要打开的文件是相对于与文件描述符fd关联的目录而不是当前工作目录确定的。如果文件描述符在没有O_SEARCH的情况下打开，则该函数将使用文件描述符下面的目录的当前许可来检查是否允许目录搜索。如果文件描述符以O_SEARCH打开，则该功能不应执行检查。

相关的功能包括：

• faccessat()
• fchmodat()
• fchownat()
• fstatat()
• linkat()
• mkdirat()
• mkfifoat()
• mknodat()
• readlinkat()
• renameat()
• symlinkat()
• unlinkat()

Answer 2

这些功能是用于写入用户空间服务器是有用的。

例如，在实现不具有'open'概念的NFS协议或文件描述符，而是依赖于持久性文件标识符时，可以使用name_to_handle_at函数来生成此持久句柄便携的方式。

然后它被发送到客户端，它将在稍后的时间返回到服务器。 然后服务器可以使用open_to_handle_at来执行操作。

有人可能会问，这比简单地在客户端和服务器之间发送完整路径名称更好。 有多种选择：

• 文件系统可以使用内部（更紧凑）表示 而不是文件名（例如基于索引节点）。
• 从句柄转到文件描述符时，可能需要完成的工作少于 。 （没有更多的路径遍历）
• 在上述的情况下，服务器上的资源消耗降低（无需跟踪打开的文件描述符在服务器端）