この API では以下のシステムコールが使用される。
.IP * 3
\fBinotify_init\fP(2) は inotify インスタンスを作成し、inotify インスタンスを参照する ファイルディスクリプタを返す。
-ã\82\82ã\81£ã\81¨æ\96°ã\81\97ã\81\84 \fBinotify_init1\fP(2) ã\82\82 \fBinotify_init\fP(2) ã\81¨å\90\8cæ§\98ã\81 ã\81\8cã\80\81ã\81\84ã\81\8fã\81¤ã\81\8bã\81®è¿½å\8a ã\81®æ©\9fè\83½ã\82\92å\88©ç\94¨ã\81\99ã\82\8bã\81\9fã\82\81ã\81®
-\fIflags\fP 引き数を持っている。
+ã\82\88ã\82\8aæ\96°ã\81\97ã\81\84 \fBinotify_init1\fP(2) ã\82\82 \fBinotify_init\fP(2) ã\81¨å\90\8cæ§\98ã\81 ã\81\8cã\80\81
+こちらにはいくつかの追加の機能を利用するための \fIflags\fP 引き数がある。
.IP *
\fBinotify_add_watch\fP(2) は inotify インスタンスに関連づけられた「監視対象 (watch) リスト」を操作する。
監視対象リストの各アイテム ("watch") は、 ファイルまたはディレクトリのパス名と、 そのパス名で参照されるファイルに対して
は新しい監視アイテムの作成や既存の監視対象の変更ができる。 各監視対象は一意の「監視対象ディスクリプタ」を持つ。 これは監視対象を作成したときに
\fBinotify_add_watch\fP(2) から返される整数である。
.IP *
-When events occur for monitored files and directories, those events are made
-available to the application as structured data that can be read from the
-inotify file descriptor using \fBread\fP(2) (see below).
+監視しているファイルやディレクトリでイベントが起こると、 それらのイベントはアプリケーションから inotify ファイルディスクリプタから
+\fBread\fP(2) を使って構造化データとして読み出すことができる (下記参照)。
.IP *
\fBinotify_rm_watch\fP(2) は inotify の監視対象リストからアイテムを削除する。
.IP *
inotify インスタンスを指している 全てのファイルディスクリプタが (\fBclose\fP(2) を使って) クローズされた場合、
その下層にあるオブジェクトとそのリソースは、 カーネルで再利用するために解放される。 関連が切られた監視対象は自動的に解放される。
-With careful programming, an application can use inotify to efficiently
-monitor and cache the state of a set of filesystem objects. However, robust
-applications should allow for the fact that bugs in the monitoring logic or
-races of the kind described below may leave the cache inconsistent with the
-filesystem state. It is probably wise to to do some consistency checking,
-and rebuild the cache when inconsistencies are detected.
+注意深くプログラミングすることで、 アプリケーションは inotify
+を使ってファイルシステムオブジェクトの集合の状態を効率的に監視しキャッシュしておくことができる。
+しかしながら、ロバストなアプリケーションでは、監視ロジックのバグや以下に説明があるような種類の競合条件によりファイルシステムの状態とキャッシュが一致しない状態になることがあるという事実も考慮に入れておくべきである。
+おそらく何らかの一貫性のチェックを行い、不一致が検出された場合にはキャッシュを再構築するのが懸命だろう。
.SS "inotify ファイルディスクリプタからのイベントの読み出し"
どのようなイベントが起こっていたかを知るには、 アプリケーションで inotify ファイルディスクリプタを \fBread\fP(2) すればよい。
これまでに何もイベントが起こっていない場合、 停止 (blocking) モードのファイルディスクリプタであれば、 少なくとも 1
監視対象ディレクトリ内でファイルやディレクトリが削除された。
.TP
\fBIN_DELETE_SELF\fP
-Watched file/directory was itself deleted. (This event also occurs if an
-object is moved to another filesystem, since \fBmv\fP(1) in effect copies the
-file to the other filesystem and then deletes it from the original
-filesystem.) In addition, an \fBIN_IGNORED\fP event will subsequently be
-generated for the watch descriptor.
+監視対象のファイルやディレクトリ自身が削除あれた。 (このイベントはオブジェクトが別のファイルシステムに移動された場合にも発生する。 \fBmv\fP(1)
+は実際には別のファイルシステムにファイルをコピーした後、元のファイルシステムからそのファイルを削除するからである。) また、
+結果的に監視ディスクリプタに対して \fBIN_IGNORED\fP イベントも生成される。
.TP
\fBIN_MODIFY\fP (*)
ファイルが変更された (\fBwrite\fP(2), \fBtruncate\fP(2) など)。
イベントが生成される。
.RE
.SS 例
-Suppose an application is watching the directory \fIdir\fP and the file
-\fIdir/myfile\fP for all events. The examples below show some events that will
-be generated for these two objects.
+アプリケーションがディレクトリ \fIdir\fP とファイル \fIdir/myfile\fP のすべてのイベントを監視しているとする。 以下に、これらの 2
+つのオブジェクトに対して生成されるイベントの例を示す。
.RS 4
.TP
fd = open("dir/myfile", O_RDWR);
\fIdir\fP と \fIdir/myfile\fP の両方に対して \fBIN_CLOSE_WRITE\fP イベントが生成される
.RE
.PP
-Suppose an application is watching the directories \fIdir1\fP and \fIdir2\fP, and
-the file \fIdir1/myfile\fP. The following examples show some events that may
-be generated.
+アプリケーションがディレクトリ \fIdir1\fP と \fIdir2\fP、およびファイル \fIdir1/myfile\fP を監視しているとする。
+以下に生成されるイベントの例を示す。
.RS 4
.TP
link("dir1/myfile", "dir2/new");
\fBIN_MOVED_TO\fP は同じ \fIcookie\fP 値を持つ。
.RE
.PP
-Suppose that \fIdir1/xx\fP and \fIdir2/yy\fP are (the only) links to the same
-file, and an application is watching \fIdir1\fP, \fIdir2\fP, \fIdir1/xx\fP, and
-\fIdir2/yy\fP. Executing the following calls in the order given below will
-generate the following events:
+\fIdir1/xx\fP と \fIdir2/yy\fP は同じファイルを参照するリンクで (他のリンクはないものとする)、 アプリケーションは \fIdir1\fP,
+\fIdir2\fP, \fIdir1/xx\fP, \fIdir2/yy\fP を監視しているものとする。
+以下に示す順序で下記の呼び出しを実行すると、以下のイベントが生成される。
.RS 4
.TP
unlink("dir2/yy");
-Generates an \fBIN_ATTRIB\fP event for \fIxx\fP (because its link count changes)
-and an \fBIN_DELETE\fP event for \fIdir2\fP.
+\fIxx\fP に対して \fBIN_ATTRIB\fP イベントが生成され (リンク数が変化したため)、 \fIdir2\fP に対して \fBIN_DELETE\fP
+イベントが生成される。
.TP
unlink("dir1/xx");
-Generates \fBIN_ATTRIB\fP, \fBIN_DELETE_SELF\fP, and \fBIN_IGNORED\fP events for
-\fIxx\fP, and an \fBIN_DELETE\fP event for \fIdir1\fP.
+\fIxx\fP に対してイベント \fBIN_ATTRIB\fP, \fBIN_DELETE_SELF\fP, \fBIN_IGNORED\fP が生成され、 \fIdir1\fP
+に対して \fBIN_DELETE\fP イベントが生成される。
.RE
.PP
-Suppose an application is watching the directory \fIdir\fP and (the empty)
-directory \fIdir/subdir\fP. The following examples show some events that may
-be generated.
+アプリケーションがディレクトリ \fIdir\fP と (空の) ディレクトリ \fIdir/subdir\fP を監視しているものとする。
+以下に生成されるイベントの例を示す。
.RS 4
.TP
mkdir("dir/new", mode);
-Generates an \fBIN_CREATE | IN_ISDIR\fP event for \fIdir\fP.
+\fIdir\fP に対して \fBIN_CREATE | IN_ISDIR\fP イベントが生成される。
.TP
rmdir("dir/subdir");
-Generates \fBIN_DELETE_SELF\fP and \fBIN_IGNORED\fP events for \fIsubdir\fP, and an
-\fBIN_DELETE | IN_ISDIR\fP event for \fIdir\fP.
+\fIsubdir\fP に対してイベント \fBIN_DELETE_SELF\fP と \fBIN_IGNORED\fP が生成され、 \fIdir\fP に対して
+\fBIN_DELETE | IN_ISDIR\fP イベントが生成される。
.RE
.SS "/proc インターフェース"
以下のインターフェースは、inotify で消費される カーネルメモリの総量を制限するのに使用できる:
inotify API では、inotify イベントが発生するきっかけとなったユーザやプロセスに関する情報は提供されない。とりわけ、inotify
経由でイベントを監視しているプロセスが、自分自身がきっかけとなったイベントと他のプロセスがきっかけとなったイベントを区別する簡単な手段はない。
-Inotify reports only events that a user\-space program triggers through the
-filesystem API. As a result, it does not catch remote events that occur on
-network filesystems. (Applications must fall back to polling the filesystem
-to catch such events.) Furthermore, various pseudo\-filesystems such as
-\fI/proc\fP, \fI/sys\fP, and \fI/dev/pts\fP are not monitorable with inotify.
+inotify は、ファイルシステム API 経由でユーザー空間プログラムがきっかけとなったイベントだけを報告する。 結果として、 inotify
+はネットワークファイルシステムで発生したリモートのイベントを捉えることはできない
+(このようなイベントを捉えるにはアプリケーションはファイルシステムをポーリングする必要がある)。 さらに、 \fI/proc\fP, \fI/sys\fP,
+\fI/dev/pts\fP といったいくつかの疑似ファイルシステムは inotify で監視することができない。
-The inotify API does not report file accesses and modifications that may
-occur because of \fBmmap\fP(2) and \fBmsync\fP(2).
+inotify API は \fBmmap\fP(2) と \fBmsync\fP(2) により起こったファイルのアクセスと変更を報告しない。
inotify API では影響が受けるファイルをファイル名で特定する。
しかしながら、アプリケーションが inotify イベントを処理する時点では、
そのファイル名がすでに削除されたり変更されたりしている可能性がある。
-The inotify API identifies events via watch descriptors. It is the
-application's responsibility to cache a mapping (if one is needed) between
-watch descriptors and pathnames. Be aware that directory renamings may
-affect multiple cached pathnames.
+inotify API では監視対象ディスクリプタを通してイベントが区別される。 (必要であれば)
+監視対象ディスクリプタとパス名のマッピングをキャッシュしておくのはアプリケーションの役目である。
+ディレクトリの名前変更の場合、キャッシュしている複数のパス名に影響がある点に注意すること。
inotify によるディレクトリの監視は再帰的に行われない: あるディレクトリ以下の
サブディレクトリを監視する場合、 監視対象を追加で作成しなければならない。
を追加した直後にサブディレクトリの内容をスキャンしたいと思う場合もあるだろう (必要ならそのサブディレクトリ内のサブディレクトリに対する watch
も再帰的に追加することもあるだろう)。
-Note that the event queue can overflow. In this case, events are lost.
-Robust applications should handle the possibility of lost events
-gracefully. For example, it may be necessary to rebuild part or all of the
-application cache. (One simple, but possibly expensive, approach is to
-close the inotify file descriptor, empty the cache, create a new inotify
-file descriptor, and then re\-create watches and cache entries for the
-objects to be monitored.)
+イベントキューはオーバーフローする場合があることに注意すること。 この場合、イベントは失なわれる。 ロバスト性が求められるアプリケーションでは、
+イベントが失なわれる可能性も含めて適切に処理を行うべきである。
+例えば、アプリケーション内のキャッシュの一部分または全てを再構築する必要があるかもしれない。 (単純だが、おそらくコストがかかる方法は、 inotify
+ファイルディスクリプタをクローズし、 キャッシュを空にし、 新しい inotify ファイルディスクリプタを作成し、
+監視しているオブジェクトの監視対象ディスクリプタとキャッシュエントリーの再作成を行う方法である。)
.SS "rename() イベントの取り扱い"
-As noted above, the \fBIN_MOVED_FROM\fP and \fBIN_MOVED_TO\fP event pair that is
-generated by \fBrename\fP(2) can be matched up via their shared cookie value.
-However, the task of matching has some challenges.
+上述の通り、 \fBrename\fP(2) により生成される \fBIN_MOVED_FROM\fP と \fBIN_MOVED_TO\fP イベントの組は、共有される
+cookie 値によって対応を取ることができる。 しかし、対応を取る場合にはいくつか難しい点がある。
-These two events are usually consecutive in the event stream available when
-reading from the inotify file descriptor. However, this is not guaranteed.
-If multiple processes are triggering events for monitored objects, then (on
-rare occasions) an arbitrary number of other events may appear between the
-\fBIN_MOVED_FROM\fP and \fBIN_MOVED_TO\fP events.
+これらの 2 つのイベントは、 inotify ファイルディスクリプタから読み出しを行った場合に、通常はイベントストリーム内で連続している。
+しかしながら、連続していることは保証されていない。 複数のプロセスが監視対象オブジェクトでイベントを発生させた場合、 (めったに起こらないことだが)
+イベント \fBIN_MOVED_FROM\fP と \fBIN_MOVED_TO\fP の間に任意の数の他のイベントがはさまる可能性がある。
-Matching up the \fBIN_MOVED_FROM\fP and \fBIN_MOVED_TO\fP event pair generated by
-\fBrename\fP(2) is thus inherently racy. (Don't forget that if an object is
-renamed outside of a monitored directory, there may not even be an
-\fBIN_MOVED_TO\fP event.) Heuristic approaches (e.g., assume the events are
-always consecutive) can be used to ensure a match in most cases, but will
-inevitably miss some cases, causing the application to perceive the
-\fBIN_MOVED_FROM\fP and \fBIN_MOVED_TO\fP events as being unrelated. If watch
-descriptors are destroyed and re\-created as a result, then those watch
-descriptors will be inconsistent with the watch descriptors in any pending
-events. (Re\-creating the inotify file descriptor and rebuilding the cache
-may be useful to deal with this scenario.)
+したがって、 \fBrename\fP(2) により生成された \fBIN_MOVED_FROM\fP と \fBIN_MOVED_TO\fP
+のイベントの組の対応を取るのは本質的に難しいことである (監視対象のディレクトリの外へオブジェクトの rename が行われた場合には
+\fBIN_MOVED_TO\fP イベントは存在しさえしないことを忘れてはならない)。 (イベントは常に連続しているとの仮定を置くといった)
+発見的な方法を使うと、ほとんどの場合でイベントの組をうまく見つけることができるが、 いくつかの場合に見逃すことが避けられず、 アプリケーションが
+\fBIN_MOVED_FROM\fP と \fBIN_MOVED_TO\fP イベントが無関係だとみなしてしまう可能性がある。
+結果的に、監視対象ディスクリプタが破棄され再作成された場合、これらの監視対象ディスクリプタは、処理待ちイベントの監視対象ディスクリプタと一貫性のないものになってしまう
+(inotify ファイルディスクリプタの再作成とキャッシュの再構成はこの状況に対処するのに有用な方法なのだが)。
-Applications should also allow for the possibility that the \fBIN_MOVED_FROM\fP
-event was the last event that could fit in the buffer returned by the
-current call to \fBread\fP(2), and the accompanying \fBIN_MOVED_TO\fP event might
-be fetched only on the next \fBread\fP(2).
+また、アプリケーションは、 \fBIN_MOVED_FROM\fP イベントが今行った \fBread\fP(2)
+の呼び出しで返されたバッファのちょうど一番最後のイベントで、 \fBIN_MOVED_TO\fP イベントは次の \fBread\fP(2)
+を行わないと取得できない可能性も考慮に入れる必要がある。
.SH バグ
.\" FIXME kernel commit 611da04f7a31b2208e838be55a42c7a1310ae321
.\" implies that unmount events were buggy 2.6.11 to 2.6.36
.\"
2.6.16 以前のカーネルでは \fBIN_ONESHOT\fP \fImask\fP フラグが働かない。
-As originally designed and implemented, the \fBIN_ONESHOT\fP flag did not cause
-an \fBIN_IGNORED\fP event to be generated when the watch was dropped after one
-event. However, as an unintended effect of other changes, since Linux
-2.6.36, an \fBIN_IGNORED\fP event is generated in this case.
+元々は設計/実装時の意図通り、 イベントが一つ発生し watch が削除された際に \fBIN_ONESHOT\fP フラグでは \fBIN_IGNORED\fP
+イベントが発生しなかった。 しかし、 別の変更での意図していなかった影響により、 Linux 2.6.36 以降では、 この場合に
+\fBIN_IGNORED\fP イベントが生成される。
.\" commit 1c17d18e3775485bf1e0ce79575eb637a94494a2
カーネル 2.6.25 より前では、 連続する同一のイベントを一つにまとめることを意図したコード (古い方のイベントがまだ読み込まれていない場合に、
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2014-04-24 00:50+0900\n"
-"PO-Revision-Date: 2014-04-27 06:31+0900\n"
+"PO-Revision-Date: 2014-04-28 02:45+0900\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"Language: \n"
"descriptor referring to the inotify instance. The more recent "
"B<inotify_init1>(2) is like B<inotify_init>(2), but has a I<flags> argument "
"that provides access to some extra functionality."
-msgstr ""
-"B<inotify_init>(2) は inotify インスタンスを作成し、inotify インスタンスを参"
-"照する ファイルディスクリプタを返す。 もっと新しい B<inotify_init1>(2) も "
-"B<inotify_init>(2) と同様だが、いくつかの追加の機能を利用するための "
-"I<flags> 引き数を持っている。"
+msgstr "B<inotify_init>(2) は inotify インスタンスを作成し、inotify インスタンスを参照する ファイルディスクリプタを返す。 より新しい B<inotify_init1>(2) も B<inotify_init>(2) と同様だが、 こちらにはいくつかの追加の機能を利用するための I<flags> 引き数がある。"
#. type: Plain text
#: build/C/man7/inotify.7:63
"When events occur for monitored files and directories, those events are made "
"available to the application as structured data that can be read from the "
"inotify file descriptor using B<read>(2) (see below)."
-msgstr ""
+msgstr "監視しているファイルやディレクトリでイベントが起こると、 それらのイベントはアプリケーションから inotify ファイルディスクリプタから B<read>(2) を使って構造化データとして読み出すことができる (下記参照)。"
#. type: Plain text
#: build/C/man7/inotify.7:72
"races of the kind described below may leave the cache inconsistent with the "
"filesystem state. It is probably wise to to do some consistency checking, "
"and rebuild the cache when inconsistencies are detected."
-msgstr ""
+msgstr "注意深くプログラミングすることで、 アプリケーションは inotify を使ってファイルシステムオブジェクトの集合の状態を効率的に監視しキャッシュしておくことができる。 しかしながら、ロバストなアプリケーションでは、監視ロジックのバグや以下に説明があるような種類の競合条件によりファイルシステムの状態とキャッシュが一致しない状態になることがあるという事実も考慮に入れておくべきである。 おそらく何らかの一貫性のチェックを行い、不一致が検出された場合にはキャッシュを再構築するのが懸命だろう。"
#. type: SS
#: build/C/man7/inotify.7:88
"file to the other filesystem and then deletes it from the original "
"filesystem.) In addition, an B<IN_IGNORED> event will subsequently be "
"generated for the watch descriptor."
-msgstr ""
+msgstr "監視対象のファイルやディレクトリ自身が削除あれた。 (このイベントはオブジェクトが別のファイルシステムに移動された場合にも発生する。 B<mv>(1) は実際には別のファイルシステムにファイルをコピーした後、元のファイルシステムからそのファイルを削除するからである。) また、 結果的に監視ディスクリプタに対して B<IN_IGNORED> イベントも生成される。"
#. type: TP
#: build/C/man7/inotify.7:247
"Suppose an application is watching the directory I<dir> and the file I<dir/"
"myfile> for all events. The examples below show some events that will be "
"generated for these two objects."
-msgstr ""
+msgstr "アプリケーションがディレクトリ I<dir> とファイル I<dir/myfile> のすべてのイベントを監視しているとする。 以下に、これらの 2 つのオブジェクトに対して生成されるイベントの例を示す。"
#. type: TP
#: build/C/man7/inotify.7:374
"Suppose an application is watching the directories I<dir1> and I<dir2>, and "
"the file I<dir1/myfile>. The following examples show some events that may "
"be generated."
-msgstr ""
+msgstr "アプリケーションがディレクトリ I<dir1> と I<dir2>、およびファイル I<dir1/myfile> を監視しているとする。 以下に生成されるイベントの例を示す。"
#. type: TP
#: build/C/man7/inotify.7:424
"file, and an application is watching I<dir1>, I<dir2>, I<dir1/xx>, and "
"I<dir2/yy>. Executing the following calls in the order given below will "
"generate the following events:"
-msgstr ""
+msgstr "I<dir1/xx> と I<dir2/yy> は同じファイルを参照するリンクで (他のリンクはないものとする)、 アプリケーションは I<dir1>, I<dir2>, I<dir1/xx>, I<dir2/yy> を監視しているものとする。 以下に示す順序で下記の呼び出しを実行すると、以下のイベントが生成される。"
#. type: TP
#: build/C/man7/inotify.7:470
#. type: Plain text
#: build/C/man7/inotify.7:481
-#, fuzzy
-#| msgid ""
-#| "Generates an B<IN_ATTRIB> event for I<myfile> and an B<IN_CREATE> event "
-#| "for I<dir2>."
msgid ""
"Generates an B<IN_ATTRIB> event for I<xx> (because its link count changes) "
"and an B<IN_DELETE> event for I<dir2>."
-msgstr ""
-"I<myfile> に対して B<IN_ATTRIB> イベントが生成され、 I<dir2> に対して "
-"B<IN_CREATE> イベントが生成される。"
+msgstr "I<xx> に対して B<IN_ATTRIB> イベントが生成され (リンク数が変化したため)、 I<dir2> に対して B<IN_DELETE> イベントが生成される。"
#. type: TP
#: build/C/man7/inotify.7:481
#. type: Plain text
#: build/C/man7/inotify.7:494
-#, fuzzy
-#| msgid ""
-#| "Generates an B<IN_ATTRIB> event for I<myfile> and an B<IN_CREATE> event "
-#| "for I<dir2>."
msgid ""
"Generates B<IN_ATTRIB>, B<IN_DELETE_SELF>, and B<IN_IGNORED> events for "
"I<xx>, and an B<IN_DELETE> event for I<dir1>."
-msgstr ""
-"I<myfile> に対して B<IN_ATTRIB> イベントが生成され、 I<dir2> に対して "
-"B<IN_CREATE> イベントが生成される。"
+msgstr "I<xx> に対してイベント B<IN_ATTRIB>, B<IN_DELETE_SELF>, B<IN_IGNORED> が生成され、 I<dir1> に対して B<IN_DELETE> イベントが生成される。"
#. type: Plain text
#: build/C/man7/inotify.7:501
"Suppose an application is watching the directory I<dir> and (the empty) "
"directory I<dir/subdir>. The following examples show some events that may "
"be generated."
-msgstr ""
+msgstr "アプリケーションがディレクトリ I<dir> と (空の) ディレクトリ I<dir/subdir> を監視しているものとする。 以下に生成されるイベントの例を示す。"
#. type: TP
#: build/C/man7/inotify.7:502
#. type: Plain text
#: build/C/man7/inotify.7:508
msgid "Generates an B<IN_CREATE | IN_ISDIR> event for I<dir>."
-msgstr ""
+msgstr "I<dir> に対して B<IN_CREATE | IN_ISDIR> イベントが生成される。"
#. type: TP
#: build/C/man7/inotify.7:508
msgid ""
"Generates B<IN_DELETE_SELF> and B<IN_IGNORED> events for I<subdir>, and an "
"B<IN_DELETE | IN_ISDIR> event for I<dir>."
-msgstr ""
+msgstr "I<subdir> に対してイベント B<IN_DELETE_SELF> と B<IN_IGNORED> が生成され、 I<dir> に対して B<IN_DELETE | IN_ISDIR> イベントが生成される。"
#. type: SS
#: build/C/man7/inotify.7:521
"network filesystems. (Applications must fall back to polling the filesystem "
"to catch such events.) Furthermore, various pseudo-filesystems such as I</"
"proc>, I</sys>, and I</dev/pts> are not monitorable with inotify."
-msgstr ""
+msgstr "inotify は、ファイルシステム API 経由でユーザー空間プログラムがきっかけとなったイベントだけを報告する。 結果として、 inotify はネットワークファイルシステムで発生したリモートのイベントを捉えることはできない (このようなイベントを捉えるにはアプリケーションはファイルシステムをポーリングする必要がある)。 さらに、 I</proc>, I</sys>, I</dev/pts> といったいくつかの疑似ファイルシステムは inotify で監視することができない。"
#. type: Plain text
#: build/C/man7/inotify.7:638
msgid ""
"The inotify API does not report file accesses and modifications that may "
"occur because of B<mmap>(2) and B<msync>(2)."
-msgstr ""
+msgstr "inotify API は B<mmap>(2) と B<msync>(2) により起こったファイルのアクセスと変更を報告しない。"
#. type: Plain text
#: build/C/man7/inotify.7:642
"application's responsibility to cache a mapping (if one is needed) between "
"watch descriptors and pathnames. Be aware that directory renamings may "
"affect multiple cached pathnames."
-msgstr ""
+msgstr "inotify API では監視対象ディスクリプタを通してイベントが区別される。 (必要であれば) 監視対象ディスクリプタとパス名のマッピングをキャッシュしておくのはアプリケーションの役目である。 ディレクトリの名前変更の場合、キャッシュしている複数のパス名に影響がある点に注意すること。"
#. type: Plain text
#: build/C/man7/inotify.7:652
"close the inotify file descriptor, empty the cache, create a new inotify "
"file descriptor, and then re-create watches and cache entries for the "
"objects to be monitored.)"
-msgstr ""
+msgstr "イベントキューはオーバーフローする場合があることに注意すること。 この場合、イベントは失なわれる。 ロバスト性が求められるアプリケーションでは、 イベントが失なわれる可能性も含めて適切に処理を行うべきである。 例えば、アプリケーション内のキャッシュの一部分または全てを再構築する必要があるかもしれない。 (単純だが、おそらくコストがかかる方法は、 inotify ファイルディスクリプタをクローズし、 キャッシュを空にし、 新しい inotify ファイルディスクリプタを作成し、 監視しているオブジェクトの監視対象ディスクリプタとキャッシュエントリーの再作成を行う方法である。)"
#. type: SS
#: build/C/man7/inotify.7:673
"As noted above, the B<IN_MOVED_FROM> and B<IN_MOVED_TO> event pair that is "
"generated by B<rename>(2) can be matched up via their shared cookie value. "
"However, the task of matching has some challenges."
-msgstr ""
+msgstr "上述の通り、 B<rename>(2) により生成される B<IN_MOVED_FROM> と B<IN_MOVED_TO> イベントの組は、共有される cookie 値によって対応を取ることができる。 しかし、対応を取る場合にはいくつか難しい点がある。"
#. type: Plain text
#: build/C/man7/inotify.7:693
"If multiple processes are triggering events for monitored objects, then (on "
"rare occasions) an arbitrary number of other events may appear between the "
"B<IN_MOVED_FROM> and B<IN_MOVED_TO> events."
-msgstr ""
+msgstr "これらの 2 つのイベントは、 inotify ファイルディスクリプタから読み出しを行った場合に、通常はイベントストリーム内で連続している。 しかしながら、連続していることは保証されていない。 複数のプロセスが監視対象オブジェクトでイベントを発生させた場合、 (めったに起こらないことだが) イベント B<IN_MOVED_FROM> と B<IN_MOVED_TO> の間に任意の数の他のイベントがはさまる可能性がある。"
#. type: Plain text
#: build/C/man7/inotify.7:718
"descriptors will be inconsistent with the watch descriptors in any pending "
"events. (Re-creating the inotify file descriptor and rebuilding the cache "
"may be useful to deal with this scenario.)"
-msgstr ""
+msgstr "したがって、 B<rename>(2) により生成された B<IN_MOVED_FROM> と B<IN_MOVED_TO> のイベントの組の対応を取るのは本質的に難しいことである (監視対象のディレクトリの外へオブジェクトの rename が行われた場合には B<IN_MOVED_TO> イベントは存在しさえしないことを忘れてはならない)。 (イベントは常に連続しているとの仮定を置くといった) 発見的な方法を使うと、ほとんどの場合でイベントの組をうまく見つけることができるが、 いくつかの場合に見逃すことが避けられず、 アプリケーションが B<IN_MOVED_FROM> と B<IN_MOVED_TO> イベントが無関係だとみなしてしまう可能性がある。 結果的に、監視対象ディスクリプタが破棄され再作成された場合、これらの監視対象ディスクリプタは、処理待ちイベントの監視対象ディスクリプタと一貫性のないものになってしまう (inotify ファイルディスクリプタの再作成とキャッシュの再構成はこの状況に対処するのに有用な方法なのだが)。"
#. type: Plain text
#: build/C/man7/inotify.7:728
"event was the last event that could fit in the buffer returned by the "
"current call to B<read>(2), and the accompanying B<IN_MOVED_TO> event might "
"be fetched only on the next B<read>(2)."
-msgstr ""
+msgstr "また、アプリケーションは、 B<IN_MOVED_FROM> イベントが今行った B<read>(2) の呼び出しで返されたバッファのちょうど一番最後のイベントで、 B<IN_MOVED_TO> イベントは次の B<read>(2) を行わないと取得できない可能性も考慮に入れる必要がある。"
#. type: SH
#: build/C/man7/inotify.7:728
"an B<IN_IGNORED> event to be generated when the watch was dropped after one "
"event. However, as an unintended effect of other changes, since Linux "
"2.6.36, an B<IN_IGNORED> event is generated in this case."
-msgstr ""
+msgstr "元々は設計/実装時の意図通り、 イベントが一つ発生し watch が削除された際に B<IN_ONESHOT> フラグでは B<IN_IGNORED> イベントが発生しなかった。 しかし、 別の変更での意図していなかった影響により、 Linux 2.6.36 以降では、 この場合に B<IN_IGNORED> イベントが生成される。"
#. commit 1c17d18e3775485bf1e0ce79575eb637a94494a2
#. type: Plain text
#: build/C/man2/inotify_rm_watch.2:75
msgid "B<inotify_add_watch>(2), B<inotify_init>(2), B<inotify>(7)"
msgstr "B<inotify_add_watch>(2), B<inotify_init>(2), B<inotify>(7)"
-
-#~ msgid "2013-09-16"
-#~ msgstr "2013-09-16"
-
-#~ msgid ""
-#~ "The following system calls are used with this API: B<inotify_init>(2) "
-#~ "(or B<inotify_init1>(2)), B<inotify_add_watch>(2), B<inotify_rm_watch>"
-#~ "(2), B<read>(2), and B<close>(2)."
-#~ msgstr ""
-#~ "以下のシステムコールがこの API と共に使用される: B<inotify_init>(2) (や "
-#~ "B<inotify_init1>(2)), B<inotify_add_watch>(2), B<inotify_rm_watch>(2), "
-#~ "B<read>(2), B<close>(2)."
-
-#~ msgid "File/directory created in watched directory (*)."
-#~ msgstr "監視対象ディレクトリ内でファイルやディレクトリが作成された。(*)"
-
-#~ msgid "Watched file/directory was itself deleted."
-#~ msgstr "監視対象のディレクトリまたはファイル自身が削除された。"
-
-#~ msgid "File was modified (*)."
-#~ msgstr "ファイルが修正された。(*)"
-
-#~ msgid ""
-#~ "Two additional convenience macros are B<IN_MOVE>, which equates to "
-#~ "IN_MOVED_FROM|IN_MOVED_TO, and B<IN_CLOSE>, which equates to "
-#~ "IN_CLOSE_WRITE|IN_CLOSE_NOWRITE."
-#~ msgstr ""
-#~ "さらに 2 つの便利なマクロがある。\n"
-#~ "B<IN_MOVE> は IN_MOVED_FROM|IN_MOVED_TO と同じで、\n"
-#~ "B<IN_CLOSE> は IN_CLOSE_WRITE|IN_CLOSE_NOWRITE と同じである。"
-
-#~ msgid "Filesystem containing watched object was unmounted."
-#~ msgstr "監視対象オブジェクトを含むファイルシステムがアンマウントされた。"
-
-#~ msgid ""
-#~ "Note that the event queue can overflow. In this case, events are lost. "
-#~ "Robust applications should handle the possibility of lost events "
-#~ "gracefully."
-#~ msgstr ""
-#~ "イベントキューは溢れる場合があることに注意すること。この場合にはイベント"
-#~ "は\n"
-#~ "失われてしまう。堅牢性が必要なアプリケーションでは、イベントが失われる可能"
-#~ "性\n"
-#~ "を適切に扱う必要がある。"
-
-#~ msgid ""
-#~ "On success, B<inotify_rm_watch>() returns zero, or -1 if an error "
-#~ "occurred (in which case, I<errno> is set appropriately)."
-#~ msgstr ""
-#~ "成功すると、 B<inotify_rm_watch>() は 0 を返す。 エラーの場合、-1 を返"
-#~ "し、 I<errno> を適切に設定する。"
-
-#~ msgid "File moved out of watched directory (*)."
-#~ msgstr "ファイルが監視対象ディレクトリ外へ移動された。(*)"
-
-#~ msgid "File moved into watched directory (*)."
-#~ msgstr "ファイルが監視対象ディレクトリ内へ移動された。(*)"
-
-#~ msgid ""
-#~ "The inotify API provides no information about the user or process that "
-#~ "triggered the inotify event."
-#~ msgstr ""
-#~ "inotify API では inotify イベントのきっかけとなったユーザやプロセスに関す"
-#~ "る\n"
-#~ "情報が提供されない。"
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2014-04-27 08:03+0900\n"
-"PO-Revision-Date: 2014-04-27 08:06+0900\n"
+"PO-Revision-Date: 2014-04-28 02:47+0900\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"Language: \n"
この API では以下のシステムコールが使用される。
.IP * 3
\fBinotify_init\fP(2) は inotify インスタンスを作成し、inotify インスタンスを参照する ファイルディスクリプタを返す。
-ã\82\82ã\81£ã\81¨æ\96°ã\81\97ã\81\84 \fBinotify_init1\fP(2) ã\82\82 \fBinotify_init\fP(2) ã\81¨å\90\8cæ§\98ã\81 ã\81\8cã\80\81ã\81\84ã\81\8fã\81¤ã\81\8bã\81®è¿½å\8a ã\81®æ©\9fè\83½ã\82\92å\88©ç\94¨ã\81\99ã\82\8bã\81\9fã\82\81ã\81®
-\fIflags\fP 引き数を持っている。
+ã\82\88ã\82\8aæ\96°ã\81\97ã\81\84 \fBinotify_init1\fP(2) ã\82\82 \fBinotify_init\fP(2) ã\81¨å\90\8cæ§\98ã\81 ã\81\8cã\80\81
+こちらにはいくつかの追加の機能を利用するための \fIflags\fP 引き数がある。
.IP *
\fBinotify_add_watch\fP(2) は inotify インスタンスに関連づけられた「監視対象 (watch) リスト」を操作する。
監視対象リストの各アイテム ("watch") は、 ファイルまたはディレクトリのパス名と、 そのパス名で参照されるファイルに対して
は新しい監視アイテムの作成や既存の監視対象の変更ができる。 各監視対象は一意の「監視対象ディスクリプタ」を持つ。 これは監視対象を作成したときに
\fBinotify_add_watch\fP(2) から返される整数である。
.IP *
-When events occur for monitored files and directories, those events are made
-available to the application as structured data that can be read from the
-inotify file descriptor using \fBread\fP(2) (see below).
+監視しているファイルやディレクトリでイベントが起こると、 それらのイベントはアプリケーションから inotify ファイルディスクリプタから
+\fBread\fP(2) を使って構造化データとして読み出すことができる (下記参照)。
.IP *
\fBinotify_rm_watch\fP(2) は inotify の監視対象リストからアイテムを削除する。
.IP *
inotify インスタンスを指している 全てのファイルディスクリプタが (\fBclose\fP(2) を使って) クローズされた場合、
その下層にあるオブジェクトとそのリソースは、 カーネルで再利用するために解放される。 関連が切られた監視対象は自動的に解放される。
-With careful programming, an application can use inotify to efficiently
-monitor and cache the state of a set of filesystem objects. However, robust
-applications should allow for the fact that bugs in the monitoring logic or
-races of the kind described below may leave the cache inconsistent with the
-filesystem state. It is probably wise to to do some consistency checking,
-and rebuild the cache when inconsistencies are detected.
+注意深くプログラミングすることで、 アプリケーションは inotify
+を使ってファイルシステムオブジェクトの集合の状態を効率的に監視しキャッシュしておくことができる。
+しかしながら、ロバストなアプリケーションでは、監視ロジックのバグや以下に説明があるような種類の競合条件によりファイルシステムの状態とキャッシュが一致しない状態になることがあるという事実も考慮に入れておくべきである。
+おそらく何らかの一貫性のチェックを行い、不一致が検出された場合にはキャッシュを再構築するのが懸命だろう。
.SS "inotify ファイルディスクリプタからのイベントの読み出し"
どのようなイベントが起こっていたかを知るには、 アプリケーションで inotify ファイルディスクリプタを \fBread\fP(2) すればよい。
これまでに何もイベントが起こっていない場合、 停止 (blocking) モードのファイルディスクリプタであれば、 少なくとも 1
監視対象ディレクトリ内でファイルやディレクトリが削除された。
.TP
\fBIN_DELETE_SELF\fP
-Watched file/directory was itself deleted. (This event also occurs if an
-object is moved to another filesystem, since \fBmv\fP(1) in effect copies the
-file to the other filesystem and then deletes it from the original
-filesystem.) In addition, an \fBIN_IGNORED\fP event will subsequently be
-generated for the watch descriptor.
+監視対象のファイルやディレクトリ自身が削除あれた。 (このイベントはオブジェクトが別のファイルシステムに移動された場合にも発生する。 \fBmv\fP(1)
+は実際には別のファイルシステムにファイルをコピーした後、元のファイルシステムからそのファイルを削除するからである。) また、
+結果的に監視ディスクリプタに対して \fBIN_IGNORED\fP イベントも生成される。
.TP
\fBIN_MODIFY\fP (*)
ファイルが変更された (\fBwrite\fP(2), \fBtruncate\fP(2) など)。
イベントが生成される。
.RE
.SS 例
-Suppose an application is watching the directory \fIdir\fP and the file
-\fIdir/myfile\fP for all events. The examples below show some events that will
-be generated for these two objects.
+アプリケーションがディレクトリ \fIdir\fP とファイル \fIdir/myfile\fP のすべてのイベントを監視しているとする。 以下に、これらの 2
+つのオブジェクトに対して生成されるイベントの例を示す。
.RS 4
.TP
fd = open("dir/myfile", O_RDWR);
\fIdir\fP と \fIdir/myfile\fP の両方に対して \fBIN_CLOSE_WRITE\fP イベントが生成される
.RE
.PP
-Suppose an application is watching the directories \fIdir1\fP and \fIdir2\fP, and
-the file \fIdir1/myfile\fP. The following examples show some events that may
-be generated.
+アプリケーションがディレクトリ \fIdir1\fP と \fIdir2\fP、およびファイル \fIdir1/myfile\fP を監視しているとする。
+以下に生成されるイベントの例を示す。
.RS 4
.TP
link("dir1/myfile", "dir2/new");
\fBIN_MOVED_TO\fP は同じ \fIcookie\fP 値を持つ。
.RE
.PP
-Suppose that \fIdir1/xx\fP and \fIdir2/yy\fP are (the only) links to the same
-file, and an application is watching \fIdir1\fP, \fIdir2\fP, \fIdir1/xx\fP, and
-\fIdir2/yy\fP. Executing the following calls in the order given below will
-generate the following events:
+\fIdir1/xx\fP と \fIdir2/yy\fP は同じファイルを参照するリンクで (他のリンクはないものとする)、 アプリケーションは \fIdir1\fP,
+\fIdir2\fP, \fIdir1/xx\fP, \fIdir2/yy\fP を監視しているものとする。
+以下に示す順序で下記の呼び出しを実行すると、以下のイベントが生成される。
.RS 4
.TP
unlink("dir2/yy");
-Generates an \fBIN_ATTRIB\fP event for \fIxx\fP (because its link count changes)
-and an \fBIN_DELETE\fP event for \fIdir2\fP.
+\fIxx\fP に対して \fBIN_ATTRIB\fP イベントが生成され (リンク数が変化したため)、 \fIdir2\fP に対して \fBIN_DELETE\fP
+イベントが生成される。
.TP
unlink("dir1/xx");
-Generates \fBIN_ATTRIB\fP, \fBIN_DELETE_SELF\fP, and \fBIN_IGNORED\fP events for
-\fIxx\fP, and an \fBIN_DELETE\fP event for \fIdir1\fP.
+\fIxx\fP に対してイベント \fBIN_ATTRIB\fP, \fBIN_DELETE_SELF\fP, \fBIN_IGNORED\fP が生成され、 \fIdir1\fP
+に対して \fBIN_DELETE\fP イベントが生成される。
.RE
.PP
-Suppose an application is watching the directory \fIdir\fP and (the empty)
-directory \fIdir/subdir\fP. The following examples show some events that may
-be generated.
+アプリケーションがディレクトリ \fIdir\fP と (空の) ディレクトリ \fIdir/subdir\fP を監視しているものとする。
+以下に生成されるイベントの例を示す。
.RS 4
.TP
mkdir("dir/new", mode);
-Generates an \fBIN_CREATE | IN_ISDIR\fP event for \fIdir\fP.
+\fIdir\fP に対して \fBIN_CREATE | IN_ISDIR\fP イベントが生成される。
.TP
rmdir("dir/subdir");
-Generates \fBIN_DELETE_SELF\fP and \fBIN_IGNORED\fP events for \fIsubdir\fP, and an
-\fBIN_DELETE | IN_ISDIR\fP event for \fIdir\fP.
+\fIsubdir\fP に対してイベント \fBIN_DELETE_SELF\fP と \fBIN_IGNORED\fP が生成され、 \fIdir\fP に対して
+\fBIN_DELETE | IN_ISDIR\fP イベントが生成される。
.RE
.SS "/proc インターフェース"
以下のインターフェースは、inotify で消費される カーネルメモリの総量を制限するのに使用できる:
inotify API では、inotify イベントが発生するきっかけとなったユーザやプロセスに関する情報は提供されない。とりわけ、inotify
経由でイベントを監視しているプロセスが、自分自身がきっかけとなったイベントと他のプロセスがきっかけとなったイベントを区別する簡単な手段はない。
-Inotify reports only events that a user\-space program triggers through the
-filesystem API. As a result, it does not catch remote events that occur on
-network filesystems. (Applications must fall back to polling the filesystem
-to catch such events.) Furthermore, various pseudo\-filesystems such as
-\fI/proc\fP, \fI/sys\fP, and \fI/dev/pts\fP are not monitorable with inotify.
+inotify は、ファイルシステム API 経由でユーザー空間プログラムがきっかけとなったイベントだけを報告する。 結果として、 inotify
+はネットワークファイルシステムで発生したリモートのイベントを捉えることはできない
+(このようなイベントを捉えるにはアプリケーションはファイルシステムをポーリングする必要がある)。 さらに、 \fI/proc\fP, \fI/sys\fP,
+\fI/dev/pts\fP といったいくつかの疑似ファイルシステムは inotify で監視することができない。
-The inotify API does not report file accesses and modifications that may
-occur because of \fBmmap\fP(2) and \fBmsync\fP(2).
+inotify API は \fBmmap\fP(2) と \fBmsync\fP(2) により起こったファイルのアクセスと変更を報告しない。
inotify API では影響が受けるファイルをファイル名で特定する。
しかしながら、アプリケーションが inotify イベントを処理する時点では、
そのファイル名がすでに削除されたり変更されたりしている可能性がある。
-The inotify API identifies events via watch descriptors. It is the
-application's responsibility to cache a mapping (if one is needed) between
-watch descriptors and pathnames. Be aware that directory renamings may
-affect multiple cached pathnames.
+inotify API では監視対象ディスクリプタを通してイベントが区別される。 (必要であれば)
+監視対象ディスクリプタとパス名のマッピングをキャッシュしておくのはアプリケーションの役目である。
+ディレクトリの名前変更の場合、キャッシュしている複数のパス名に影響がある点に注意すること。
inotify によるディレクトリの監視は再帰的に行われない: あるディレクトリ以下の
サブディレクトリを監視する場合、 監視対象を追加で作成しなければならない。
を追加した直後にサブディレクトリの内容をスキャンしたいと思う場合もあるだろう (必要ならそのサブディレクトリ内のサブディレクトリに対する watch
も再帰的に追加することもあるだろう)。
-Note that the event queue can overflow. In this case, events are lost.
-Robust applications should handle the possibility of lost events
-gracefully. For example, it may be necessary to rebuild part or all of the
-application cache. (One simple, but possibly expensive, approach is to
-close the inotify file descriptor, empty the cache, create a new inotify
-file descriptor, and then re\-create watches and cache entries for the
-objects to be monitored.)
+イベントキューはオーバーフローする場合があることに注意すること。 この場合、イベントは失なわれる。 ロバスト性が求められるアプリケーションでは、
+イベントが失なわれる可能性も含めて適切に処理を行うべきである。
+例えば、アプリケーション内のキャッシュの一部分または全てを再構築する必要があるかもしれない。 (単純だが、おそらくコストがかかる方法は、 inotify
+ファイルディスクリプタをクローズし、 キャッシュを空にし、 新しい inotify ファイルディスクリプタを作成し、
+監視しているオブジェクトの監視対象ディスクリプタとキャッシュエントリーの再作成を行う方法である。)
.SS "rename() イベントの取り扱い"
-As noted above, the \fBIN_MOVED_FROM\fP and \fBIN_MOVED_TO\fP event pair that is
-generated by \fBrename\fP(2) can be matched up via their shared cookie value.
-However, the task of matching has some challenges.
+上述の通り、 \fBrename\fP(2) により生成される \fBIN_MOVED_FROM\fP と \fBIN_MOVED_TO\fP イベントの組は、共有される
+cookie 値によって対応を取ることができる。 しかし、対応を取る場合にはいくつか難しい点がある。
-These two events are usually consecutive in the event stream available when
-reading from the inotify file descriptor. However, this is not guaranteed.
-If multiple processes are triggering events for monitored objects, then (on
-rare occasions) an arbitrary number of other events may appear between the
-\fBIN_MOVED_FROM\fP and \fBIN_MOVED_TO\fP events.
+これらの 2 つのイベントは、 inotify ファイルディスクリプタから読み出しを行った場合に、通常はイベントストリーム内で連続している。
+しかしながら、連続していることは保証されていない。 複数のプロセスが監視対象オブジェクトでイベントを発生させた場合、 (めったに起こらないことだが)
+イベント \fBIN_MOVED_FROM\fP と \fBIN_MOVED_TO\fP の間に任意の数の他のイベントがはさまる可能性がある。
-Matching up the \fBIN_MOVED_FROM\fP and \fBIN_MOVED_TO\fP event pair generated by
-\fBrename\fP(2) is thus inherently racy. (Don't forget that if an object is
-renamed outside of a monitored directory, there may not even be an
-\fBIN_MOVED_TO\fP event.) Heuristic approaches (e.g., assume the events are
-always consecutive) can be used to ensure a match in most cases, but will
-inevitably miss some cases, causing the application to perceive the
-\fBIN_MOVED_FROM\fP and \fBIN_MOVED_TO\fP events as being unrelated. If watch
-descriptors are destroyed and re\-created as a result, then those watch
-descriptors will be inconsistent with the watch descriptors in any pending
-events. (Re\-creating the inotify file descriptor and rebuilding the cache
-may be useful to deal with this scenario.)
+したがって、 \fBrename\fP(2) により生成された \fBIN_MOVED_FROM\fP と \fBIN_MOVED_TO\fP
+のイベントの組の対応を取るのは本質的に難しいことである (監視対象のディレクトリの外へオブジェクトの rename が行われた場合には
+\fBIN_MOVED_TO\fP イベントは存在しさえしないことを忘れてはならない)。 (イベントは常に連続しているとの仮定を置くといった)
+発見的な方法を使うと、ほとんどの場合でイベントの組をうまく見つけることができるが、 いくつかの場合に見逃すことが避けられず、 アプリケーションが
+\fBIN_MOVED_FROM\fP と \fBIN_MOVED_TO\fP イベントが無関係だとみなしてしまう可能性がある。
+結果的に、監視対象ディスクリプタが破棄され再作成された場合、これらの監視対象ディスクリプタは、処理待ちイベントの監視対象ディスクリプタと一貫性のないものになってしまう
+(inotify ファイルディスクリプタの再作成とキャッシュの再構成はこの状況に対処するのに有用な方法なのだが)。
-Applications should also allow for the possibility that the \fBIN_MOVED_FROM\fP
-event was the last event that could fit in the buffer returned by the
-current call to \fBread\fP(2), and the accompanying \fBIN_MOVED_TO\fP event might
-be fetched only on the next \fBread\fP(2).
+また、アプリケーションは、 \fBIN_MOVED_FROM\fP イベントが今行った \fBread\fP(2)
+の呼び出しで返されたバッファのちょうど一番最後のイベントで、 \fBIN_MOVED_TO\fP イベントは次の \fBread\fP(2)
+を行わないと取得できない可能性も考慮に入れる必要がある。
.SH バグ
.\" FIXME kernel commit 611da04f7a31b2208e838be55a42c7a1310ae321
.\" implies that unmount events were buggy 2.6.11 to 2.6.36
.\"
2.6.16 以前のカーネルでは \fBIN_ONESHOT\fP \fImask\fP フラグが働かない。
-As originally designed and implemented, the \fBIN_ONESHOT\fP flag did not cause
-an \fBIN_IGNORED\fP event to be generated when the watch was dropped after one
-event. However, as an unintended effect of other changes, since Linux
-2.6.36, an \fBIN_IGNORED\fP event is generated in this case.
+元々は設計/実装時の意図通り、 イベントが一つ発生し watch が削除された際に \fBIN_ONESHOT\fP フラグでは \fBIN_IGNORED\fP
+イベントが発生しなかった。 しかし、 別の変更での意図していなかった影響により、 Linux 2.6.36 以降では、 この場合に
+\fBIN_IGNORED\fP イベントが生成される。
.\" commit 1c17d18e3775485bf1e0ce79575eb637a94494a2
カーネル 2.6.25 より前では、 連続する同一のイベントを一つにまとめることを意図したコード (古い方のイベントがまだ読み込まれていない場合に、
-# pagename,#complete,#remaining,#all
-inotify.7,133,20,153
○:LDP man-pages:3.65:2012/08/05:hier:7:2014/04/24::nakano@apm.seikei.ac.jp:NAKANO Takeo:
○:LDP man-pages:3.65:2010/11/07:hostname:7:2014/04/24::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.65:2012/05/10:icmp:7:2014/04/24::amotoki@gmail.com:Akihiro MOTOKI:
-â\98\86:LDP man-pages:3.63=>3.65:2014/04/01:inotify:7:2014/04/14::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.65:2014/04/01:inotify:7:2014/04/28::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.65:2007/10/23:intro:7:2014/04/24::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.65:2013/09/17:ip:7:2014/04/24::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.65:2012/12/16:ipv6:7:2014/04/24::amotoki@gmail.com:Akihiro MOTOKI:
<TR><TD ALIGN="center" COLSPAN=3 BGCOLOR="Yellow"><B>filesystem</B></TD></TR>
<TR class="over80"><TD>spu_create.2</TD><TD>13/78</TD><TD>83.33</TD></TR>
<TR class="over70"><TD>spufs.7</TD><TD>41/159</TD><TD>74.21</TD></TR>
-<TR><TD ALIGN="center" COLSPAN=3 BGCOLOR="Yellow"><B>inotify</B></TD></TR>
-<TR class="over80"><TD>inotify.7</TD><TD>20/153</TD><TD>86.93</TD></TR>
<TR><TD ALIGN="center" COLSPAN=3 BGCOLOR="Yellow"><B>intro</B></TD></TR>
<TR class="over80"><TD>proc.5</TD><TD>78/966</TD><TD>91.93</TD></TR>
<TR><TD ALIGN="center" COLSPAN=3 BGCOLOR="Yellow"><B>keyutils</B></TD></TR>
<TR class="over70"><TD>futimesat.2</TD><TD>10/37</TD><TD>72.97</TD></TR>
<TR><TD>utimensat.2</TD><TD>49/107</TD><TD>54.21</TD></TR>
<TR class="over80"><TD>zdump.8</TD><TD>1/22</TD><TD>95.45</TD></TR>
-<TR><TD COLSPAN=3>Total 53 pages</TD></TR>
+<TR><TD COLSPAN=3>Total 52 pages</TD></TR>
</TABLE>
</BODY></HTML>
OSDN Git Service
