name_to_handle_at（）のロジック

Question

新しいシステムコールname_to_handle_at（）とopen_to_handle_at（）に関する情報があまり得られません。誰でもここで私を助けることができますか？

ありがとう

編集。私はちょうどこの

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

Answer 1

を持っている私はそのようなopenat()として、これらの機能は、POSIX 2008に追加*at()機能の一部またはすべてをサポートするために必要とされることを前提とするために傾斜させることになります。

#include <fcntl.h> 

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

openat()関数は、pathが相対パスを指定する場合を除いて、open()関数と等価でなければなりません。この場合、開かれるファイルは、現在の作業ディレクトリの代わりにファイル記述子fdに関連付けられたディレクトリに関連して決定されます。ファイルディスクリプタがO_SEARCHなしで開かれた場合、ファイルディスクリプタの基礎となるディレクトリの現在のアクセス権を使用してディレクトリ検索が許可されているかどうかをチェックします。ファイルディスクリプタがO_SEARCHで開かれた場合、関数はチェックを実行してはならない。

関連の機能は次のとおり

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

Answer 2

これらの機能は、ユーザ空間サーバーを作成する場合に便利です。

たとえば、 'オープン'概念を持たないNFSプロトコルを実装する場合、またはファイル記述子ではなく永続的なファイル識別子を使用する場合、name_to_handle_at関数を使用して、この永続ハンドルをポータブルな方法。

これはクライアントに送信され、後でサーバーに返されます。 サーバーはopen_to_handle_atを使用して操作を実行できます。

クライアントとサーバーの間で完全なパス名を送信するよりも、これがどのように優れているかを尋ねることができます。オプションの 数：

• ファイルシステムは、内部（よりコンパクトな）表現を使用することができ 代わりにファイル名（例えば、iノードに基づきます）。
• ハンドルからファイル記述子に移動するときには、 の作業を減らす必要があります。 （これ以上のパストラバーサル）上記のシナリオでは
• 、サーバー上のリソース消費量が低減される（サーバ側で開いているファイル記述子を追跡する必要はありません）