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來執行操作。

有人可能會問，這比簡單地在客戶端和服務器之間發送完整路徑名稱更好。 有多種選擇：

• 文件系統可以使用內部（更緊湊）表示 而不是文件名（例如基於索引節點）。
• 從句柄轉到文件描述符時，可能需要完成的工作少於 。 （沒有更多的路徑遍歷）
• 在上述的情況下，服務器上的資源消耗降低（無需跟蹤打開的文件描述符在服務器端）