2

inotify を使用してディレクトリを監視しようとしていますが、すべてのイベントに登録しています。現在、私のプロジェクトでは、ディレクトリに対して実行された MOVE_SELF 操作を追跡する必要があるため、監視対象のディレクトリが移動した新しい場所を検出できる必要があります。これを達成するために、監視対象のディレクトリの開いているファイル記述子 (int fd) の参照を保存しています。MOVE_SELF を取得すると、次を使用して新しいパスを取得しようとします。

//code to store a reference of file-descrptor of the monitored sirectory
fd = open(watchPath.c_str(), O_RDONLY)    


//code to learn the new location of the moved directory
char fdpath[4096];
char path[4096];

sprintf(fdpath, "/proc/self/fd/%d", fd);
ssize_t sz = readlink(fdpath, path, sizeof(path) - 1); //Path will contain the new location after the move happens

ただし、これの副作用は、ディレクトリを削除した場合、保持している開いているファイル記述子がまだあるため、DELETE_SELF イベントが発生しないことです。この問題を回避する方法を誰かに教えてもらえますか?

ありがとう、 -サンディープ

4

1 に答える 1

3

誰かがこの問題に遭遇した場合: これは間違いなく予想される動作です。inotify は「ファイル」を監視するのではなく、「ファイル オブジェクト」 (別名 inode) を監視します。inode は、それを指している開いているすべてのファイル記述子が閉じられるまで、カーネルによって削除されません。

IN_DELETEファイルへの複数のハード リンクの 1 つを削除すると、 /IN_DELETE_SELFがトリガーされないのもこのためです (ハード リンクは同じ inode を共有するため)。

イベントをサブスクライブすることで、ハード リンクの問題を部分的に回避できますIN_ATTRIB。これは、inode の参照カウントが変更されたとき (たとえば、ハード リンクの 1 つが削除されたとき) にトリガーされるため、古いリンクにファイルがまだ存在するかどうかを確認するために使用できます。道。

「オープン記述子」の問題については、回避策を知りません。個人的には、私は気にしません。では、プログラムがディスクの内容と一時的に非同期になったらどうなるでしょうか。inotify が完全に完璧だったとしても、キューのオーバーランやイベントの競合のために、時々再同期が必要になります。

于 2016-12-27T09:22:37.860 に答える