From 43c72fc15aac3eb6ba81e929437f4534ff8890bf Mon Sep 17 00:00:00 2001
From: Akihiro MOTOKI <amotoki@gmail.com>
Date: Mon, 28 Apr 2014 00:08:10 +0900
Subject: [PATCH] (split) LDP: Translate open.2

---
 draft/man2/open.2   | 125 ++++++++++++----------------
 po4a/stdio/po/ja.po |  42 ++++------
 release/man2/open.2 | 231 +++++++++++++++++++++-------------------------------
 stats/stdio         |   1 -
 translation_list    |   2 +-
 untrans.html        |   3 +-
 6 files changed, 164 insertions(+), 240 deletions(-)

diff --git a/draft/man2/open.2 b/draft/man2/open.2
index dfd1f476..1c812bdf 100644
--- a/draft/man2/open.2
+++ b/draft/man2/open.2
@@ -263,13 +263,11 @@ flag) を 0 個以上「ビット単位の OR (bitwise\-or)」で 指定する
 で追加された。
 .TP 
 \fBO_DSYNC\fP
-Write operations on the file will complete according to the requirements of
-synchronized I/O \fIdata\fP integrity completion.
+ファイルに対する書き込み操作は、同期 I/O の\fIデータ\fP完全性完了の要件に基づいて行われる。
 
-By the time \fBwrite\fP(2)  (and similar)  return, the output data has been
-transferred to the underlying hardware, along with any file metadata that
-would be required to retrieve that data (i.e., as though each \fBwrite\fP(2)
-was followed by a call to \fBfdatasync\fP(2)).  \fISee NOTES below\fP.
+\fBwrite\fP(2) (や同様のコール) が返るまでに、
+書き込まれたデータおよびデータを取得するのに必要なファイルメタデータが裏で利用されているハードウェアに転送される (つまり、\fBwrite\fP(2)
+の後に \fBfdatasync\fP(2) を呼び出したのと同じようになる)。 \fI下記の「注意」も参照のこと\fP。
 .TP 
 \fBO_EXCL\fP
 この呼び出しでファイルが作成されることを保証する。このフラグが \fBO_CREAT\fP と
@@ -376,15 +374,11 @@ PID を組み合わせた名前) を作成し、 \fBlink\fP(2)  を使用して
 \fIdirfd\fP 引数として使うことで、 そのシンボリックリンクに対して操作を行うことができる。
 .TP 
 \fBO_SYNC\fP
-Write operations on the file will complete according to the requirements of
-synchronized I/O \fIfile\fP integrity completion (by contrast with contrast
-with the synchronized I/O \fIdata\fP integrity completion provided by
-\fBO_DSYNC\fP.)
+ファイルに対する書き込み操作は、同期 I/O の\fIファイル\fP完全性完了の要件に基づいて行われる (これに対し \fBO_DSYNC\fP では同期 I/O
+の\fIデータ\fP完全性完了が提供される)。
 
-By the time \fBwrite\fP(2)  (and similar)  return, the output data and
-associated file metadata have been transferred to the underlying hardware
-(i.e., as though each \fBwrite\fP(2)  was followed by a call to \fBfsync\fP(2)).
-\fISee NOTES below\fP.
+\fBwrite\fP(2) (や同様のコール) が返るまでに、 書き込まれたデータと関連するファイルメタデータが裏で利用されているハードウェアに転送される
+(つまり、\fBwrite\fP(2) の後に \fBfsync\fP(2) を呼び出したのと同じようになる)。 \fI下記の「注意」も参照のこと\fP。
 .TP 
 \fBO_TMPFILE\fP (Linux 3.11 以降)
 .\" commit 60545d0d4610b02e55f65d141c95b18ccf855b6e
@@ -433,10 +427,9 @@ linkat(AT_FDCWD, path, AT_FDCWD, "/path/for/file",
 .IP
 .\" commit 99b6436bc29e4f10e4388c27a3e4810191cc4788
 .\" commit ab29743117f9f4c22ac44c13c1647fb24fb2bafe
-\fBO_TMPFILE\fP requires support by the underlying filesystem; only a subset of
-Linux filesystems provide that support.  In the initial implementation,
-support was provided in the ext2, ext3, ext4, UDF, Minix, and shmem
-filesystems.  XFS support was added in Linux 3.15.
+\fBO_TMPFILE\fP は、 裏で利用されるファイルシステムによるサポートが必要である。 一部の Linux
+ファイルシステムだけがこの機能をサポートしている。 最初の実装では、 ext2, ext3, ext4, UDF, Minix, shmem
+ファイルシステムがサポートしていた。 XFS でのサポートが Linux 3.15 で追加された。
 .TP 
 \fBO_TRUNC\fP
 ファイルが既に存在し、通常ファイルであり、 アクセスモードで書き込みが許可されている (つまり、 \fBO_RDWR\fP または \fBO_WRONLY\fP
@@ -617,48 +610,37 @@ Linux では、 \fBO_NONBLOCK\fP フラグは、 open を実行したいが read
 (それぞれ最終アクセス時刻、最終状態変更時刻、最終修正時刻である。 \fBstat\fP(2)  参照) が現在時刻に設定される。 さらに親ディレクトリの
 \fIst_ctime\fP と \fIst_mtime\fP も現在時刻に設定される。 それ以外の場合で、O_TRUNC フラグでファイルが修正されたときは、
 ファイルの \fIst_ctime\fP と \fIst_mtime\fP フィールドが現在時刻に設定される。
-.SS 同期入出力
-The POSIX.1\-2008 "synchronized I/O" option specifies different variants of
-synchronized I/O, and specifies the \fBopen\fP()  flags \fBO_SYNC\fP, \fBO_DSYNC\fP,
-and \fBO_RSYNC\fP for controlling the behavior.  Regardless of whether an
-implementation supports this option, it must at least support the use of
-\fBO_SYNC\fP for regular files.
-
-Linux implements \fBO_SYNC\fP and \fBO_DSYNC\fP, but not \fBO_RSYNC\fP.  (Somewhat
-incorrectly, glibc defines \fBO_RSYNC\fP to have the same value as \fBO_SYNC\fP.)
-
-\fBO_SYNC\fP provides synchronized I/O \fIfile\fP integrity completion, meaning
-write operations will flush data and all associated metadata to the
-underlying hardware.  \fBO_DSYNC\fP provides synchronized I/O \fIdata\fP integrity
-completion, meaning write operations will flush data to the underlying
-hardware, but will only flush metadata updates that are required to allow a
-subsequent read operation to complete successfully.  Data integrity
-completion can reduce the number of disk operations that are required for
-applications that don't need the guarantees of file integrity completion.
-
-To understand the difference between the the two types of completion,
-consider two pieces of file metadata: the file last modification timestamp
-(\fIst_mtime\fP)  and the file length.  All write operations will update the
-last file modification timestamp, but only writes that add data to the end
-of the file will change the file length.  The last modification timestamp is
-not needed to ensure that a read completes successfully, but the file length
-is.  Thus, \fBO_DSYNC\fP would only guarantee to flush updates to the file
-length metadata (whereas \fBO_SYNC\fP would also always flush the last
-modification timestamp metadata).
-
-Before Linux 2.6.33, Linux implemented only the \fBO_SYNC\fP flag for
-\fBopen\fP().  However, when that flag was specified, most filesystems actually
-provided the equivalent of synchronized I/O \fIdata\fP integrity completion
-(i.e., \fBO_SYNC\fP was actually implemented as the equivalent of \fBO_DSYNC\fP).
+.SS "同期 I/O"
+POSIX.1\-2008 の「同期 I/O」の選択肢として複数種類が規定されており、 動作を制御するために \fBopen\fP() フラグとして
+\fBO_SYNC\fP, \fBO_DSYNC\fP, \fBO_RSYNC\fP が規定されている。 この選択肢を実装がサポートしているかに関わらず、
+各実装では少なくとも通常のファイルに対して \fBO_SYNC\fP が利用できなければならない。
+
+Linux は \fBO_SYNC\fP と \fBO_DSYNC\fP を実装しているが、 \fBO_RSYNC\fP は実装していない (少し間違っているのだが、
+glibc では \fBO_RSYNC\fP が \fBO_SYNC\fP と同じ値で定義されている)。
+
+\fBO_SYNC\fP は、 同期 I/O での\fIファイル\fP完全性完了を提供する。 つまり、
+書き込み操作はデータとすべての関連メタデータを裏で利用されているハードウェアにフラッシュすることを意味する。 \fBO_DSYNC\fP は、 同期 I/O
+での\fIデータ\fP完全性完了を提供する。 つまり、 書き込み操作はデータを裏で利用されているハードウェアにフラッシュするが、
+それ以降の読み出し操作が正常に完了するのに必要なメタデータの更新のみをフラッシュする。 データ完全性完了は、
+ファイル完全性完了を必要としないアプリケーションで、 ディスク操作の数を減らすことができる。
+
+2 種類の完了の違いを理解するために、 ファイルメタデータの 2 つの要素、 ファイルの最終修正時刻 (\fIst_mtime\fP)
+とファイル長、を考える。 すべての書き込み操作は最終修正時刻を更新するが、 ファイルの末尾にデータを追加する書き込み操作のみがファイル長を変更する。
+最終修正時刻は、 読み出しが正常に完了するのに必要ではないが、 ファイル長は必要である。 したがって、 \fBO_DSYNC\fP
+はファイル長のメタデータの更新がフラッシュされることだけを保証する (これに対して \fBO_SYNC\fP
+では最終修正時刻のメタデータも常にフラッシュされる)。
+
+Linux 2.6.33 より前では、 Linux は \fBopen\fP() では \fBO_SYNC\fP フラグのみを実装していた。 しかしながら、
+このフラグが指定された場合、 ほとんどのファイルシステムで提供されていたのは実際には同期 I/O での\fIデータ\fP完全性完了と等価なものであった
+(つまり、 \fBO_SYNC\fP は実際には \fBO_DSYNC\fP と等価なものとして実装されていた)。
 
 .\"
 .\"
-Since Linux 2.6.33, proper \fBO_SYNC\fP support is provided.  However, to
-ensure backward binary compatibility, \fBO_DSYNC\fP was defined with the same
-value as the historical \fBO_SYNC\fP, and \fBO_SYNC\fP was defined as a new
-(two\-bit) flag value that includes the \fBO_DSYNC\fP flag value.  This ensures
-that applications compiled against new headers get at least \fBO_DSYNC\fP
-semantics on pre\-2.6.33 kernels.
+Linux 2.6.33 行こう では、 正しい \fBO_SYNC\fP のサポートが提供されている。 しかしながら、
+バイナリレベルの後方互換性を保証するため、 \fBO_DSYNC\fP は以前の \fBO_SYNC\fP と同じ値で定義されており、 \fBO_SYNC\fP は
+\fBO_DSYNC\fP フラグの値を含む新しい (2 ビットの) フラグ値として定義されている。 これにより、
+新しいヘッダを使ってコンパイルされたアプリケーションで、 2.6.33 より前のカーネルで少なくとも \fBO_DSYNC\fP
+の動作は同じになることが保証される。
 .SS NFS
 NFS を実現しているプロトコルには多くの不備があり、特に \fBO_SYNC\fP と \fBO_NDELAY\fP に影響する。
 
@@ -685,29 +667,24 @@ Linux では、特別な、非標準なアクセスモードとして 3 (バイ
 この非標準のアクセスモードはいくつかの Linux ドライバで、デバイス固有の \fBioctl\fP(2)
 操作にのみ使用されるディスクリプタを返すために使われている。
 .SS "openat() や他のディレクトリファイルディスクリプタ API の基本原理"
-\fBopenat\fP()  and the other system calls and library functions that take a
-directory file descriptor argument (i.e., \fBfaccessat\fP(2),
+\fBopenat\fP() やディレクトリファイルディスクリプタを引き数を取る他のシステムコールやライブラリ関数 (\fBfaccessat\fP(2),
 \fBfanotify_mark\fP(2), \fBfchmodat\fP(2), \fBfchownat\fP(2), \fBfstatat\fP(2),
 \fBfutimesat\fP(2), \fBlinkat\fP(2), \fBmkdirat\fP(2), \fBmknodat\fP(2),
 \fBname_to_handle_at\fP(2), \fBreadlinkat\fP(2), \fBrenameat\fP(2), \fBsymlinkat\fP(2),
-\fBunlinkat\fP(2), \fButimensat\fP(2)  \fBmkfifoat\fP(3), and \fBscandirat\fP(3))  are
-supported for two reasons.  Here, the explanation is in terms of the
-\fBopenat\fP()  call, but the rationale is analogous for the other interfaces.
-
-First, \fBopenat\fP()  allows an application to avoid race conditions that
-could occur when using \fBopen\fP()  to open files in directories other than
-the current working directory.  These race conditions result from the fact
-that some component of the directory prefix given to \fBopen\fP()  could be
-changed in parallel with the call to \fBopen\fP().  Such races can be avoided
-by opening a file descriptor for the target directory, and then specifying
-that file descriptor as the \fIdirfd\fP argument of \fBopenat\fP().
+\fBunlinkat\fP(2), \fButimensat\fP(2) \fBmkfifoat\fP(3), \fBscandirat\fP(3))
+は二つの理由から用意されている。 ここでは、 \fBopenat\fP コールに関して説明するが、この基本原理は他のインターフェースでも同じである。
+
+最初の理由として、 \fBopenat\fP() を使うと、 アプリケーションは、 カレントワーキングディレクトリ以外のディレクトリで \fBopen\fP()
+を使ってファイルをオープンする際に起こり得る競合条件を避けることができる。 これらの競合条件は、 \fBopen\fP()
+に渡されたディレクトリプレフィックスの構成要素が \fBopen\fP() の呼び出しと並行して変化する可能性があるという点に由来している。
+このような競合条件は、 対象のディレクトリに対するファイルディスクリプタをオープンし、 それから \fBopenat\fP() の \fIdirfd\fP
+引き数としてそのファイルディスクリプタを指定することで、 避けることができる。
 
 .\"
 .\"
-Second, \fBopenat\fP()  allows the implementation of a per\-thread "current
-working directory", via file descriptor(s) maintained by the application.
-(This functionality can also be obtained by tricks based on the use of
-\fI/proc/self/fd/\fPdirfd, but less efficiently.)
+二つ目として、 \fBopenat\fP() を使うと、アプリケーションが管理するファイルディスクリプタにより、
+スレッド単位の「カレントワーキングディレクトリ」を実装することができる (この機能は、 \fI/proc/self/fd/dirfd\fP
+を使った方法でも実現することができるが、 効率の面で落とる)。
 .SS O_DIRECT
 .LP
 \fBO_DIRECT\fP フラグを使用する場合、ユーザ空間バッファの長さやアドレス、 I/O
diff --git a/po4a/stdio/po/ja.po b/po4a/stdio/po/ja.po
index 6eb2a3ee..aa962008 100644
--- a/po4a/stdio/po/ja.po
+++ b/po4a/stdio/po/ja.po
@@ -7,7 +7,7 @@ msgid ""
 msgstr ""
 "Project-Id-Version: PACKAGE VERSION\n"
 "POT-Creation-Date: 2014-04-27 09:26+0900\n"
-"PO-Revision-Date: 2014-04-27 09:20+0900\n"
+"PO-Revision-Date: 2014-04-28 00:05+0900\n"
 "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
 "Language-Team: LANGUAGE <LL@li.org>\n"
 "Language: \n"
@@ -6858,7 +6858,7 @@ msgstr "B<O_DSYNC>"
 msgid ""
 "Write operations on the file will complete according to the requirements of "
 "synchronized I/O I<data> integrity completion."
-msgstr ""
+msgstr "ファイルに対する書き込み操作は、同期 I/O のI<データ>完全性完了の要件に基づいて行われる。"
 
 #. type: Plain text
 #: build/C/man2/open.2:382
@@ -6867,7 +6867,7 @@ msgid ""
 "transferred to the underlying hardware, along with any file metadata that "
 "would be required to retrieve that data (i.e., as though each B<write>(2)  "
 "was followed by a call to B<fdatasync>(2)).  I<See NOTES below>."
-msgstr ""
+msgstr "B<write>(2) (や同様のコール) が返るまでに、 書き込まれたデータおよびデータを取得するのに必要なファイルメタデータが裏で利用されているハードウェアに転送される (つまり、B<write>(2) の後に B<fdatasync>(2) を呼び出したのと同じようになる)。 I<下記の「注意」も参照のこと>。"
 
 #. type: TP
 #: build/C/man2/open.2:382
@@ -7184,7 +7184,7 @@ msgid ""
 "synchronized I/O I<file> integrity completion (by contrast with contrast "
 "with the synchronized I/O I<data> integrity completion provided by "
 "B<O_DSYNC>.)"
-msgstr ""
+msgstr "ファイルに対する書き込み操作は、同期 I/O のI<ファイル>完全性完了の要件に基づいて行われる (これに対し B<O_DSYNC> では同期 I/O のI<データ>完全性完了が提供される)。"
 
 #. type: Plain text
 #: build/C/man2/open.2:622
@@ -7193,7 +7193,7 @@ msgid ""
 "associated file metadata have been transferred to the underlying hardware (i."
 "e., as though each B<write>(2)  was followed by a call to B<fsync>(2)).  "
 "I<See NOTES below>."
-msgstr ""
+msgstr "B<write>(2) (や同様のコール) が返るまでに、 書き込まれたデータと関連するファイルメタデータが裏で利用されているハードウェアに転送される (つまり、B<write>(2) の後に B<fsync>(2) を呼び出したのと同じようになる)。 I<下記の「注意」も参照のこと>。"
 
 #. type: TP
 #: build/C/man2/open.2:622
@@ -7317,22 +7317,12 @@ msgstr ""
 #.  commit ab29743117f9f4c22ac44c13c1647fb24fb2bafe
 #. type: Plain text
 #: build/C/man2/open.2:717
-#, fuzzy
-#| msgid ""
-#| "B<O_TMPFILE> requires support by the underlying filesystem; only a subset "
-#| "of Linux filesystems provide that support.  In the initial "
-#| "implementation, support was provided in the ex2, ext3, ext4, UDF, Minix, "
-#| "and shmem filesystems.  XFS support was added in Linux 3.15."
 msgid ""
 "B<O_TMPFILE> requires support by the underlying filesystem; only a subset of "
 "Linux filesystems provide that support.  In the initial implementation, "
 "support was provided in the ext2, ext3, ext4, UDF, Minix, and shmem "
 "filesystems.  XFS support was added in Linux 3.15."
-msgstr ""
-"B<O_TMPFILE> は、 内部で利用されるファイルシステムによるサポートが必要であ"
-"る。 一部の Linux ファイルシステムだけがこの機能をサポートしている。 最初の実"
-"装では、 ext2, ext3, ext4, UDF, Minix, shmem ファイルシステムがサポートしてい"
-"た。 XFS でのサポートが Linux 3.15 で追加された。"
+msgstr "B<O_TMPFILE> は、 裏で利用されるファイルシステムによるサポートが必要である。 一部の Linux ファイルシステムだけがこの機能をサポートしている。 最初の実装では、 ext2, ext3, ext4, UDF, Minix, shmem ファイルシステムがサポートしていた。 XFS でのサポートが Linux 3.15 で追加された。"
 
 #. type: TP
 #: build/C/man2/open.2:717
@@ -7869,7 +7859,7 @@ msgstr ""
 #: build/C/man2/open.2:1104
 #, no-wrap
 msgid "Synchronized I/O"
-msgstr "同期入出力"
+msgstr "同期 I/O"
 
 #. type: Plain text
 #: build/C/man2/open.2:1119
@@ -7879,14 +7869,14 @@ msgid ""
 "and B<O_RSYNC> for controlling the behavior.  Regardless of whether an "
 "implementation supports this option, it must at least support the use of "
 "B<O_SYNC> for regular files."
-msgstr ""
+msgstr "POSIX.1-2008 の「同期 I/O」の選択肢として複数種類が規定されており、 動作を制御するために B<open>() フラグとして B<O_SYNC>, B<O_DSYNC>, B<O_RSYNC> が規定されている。 この選択肢を実装がサポートしているかに関わらず、 各実装では少なくとも通常のファイルに対して B<O_SYNC> が利用できなければならない。"
 
 #. type: Plain text
 #: build/C/man2/open.2:1130
 msgid ""
 "Linux implements B<O_SYNC> and B<O_DSYNC>, but not B<O_RSYNC>.  (Somewhat "
 "incorrectly, glibc defines B<O_RSYNC> to have the same value as B<O_SYNC>.)"
-msgstr ""
+msgstr "Linux は B<O_SYNC> と B<O_DSYNC> を実装しているが、 B<O_RSYNC> は実装していない (少し間違っているのだが、 glibc では B<O_RSYNC> が B<O_SYNC> と同じ値で定義されている)。"
 
 #. type: Plain text
 #: build/C/man2/open.2:1148
@@ -7899,7 +7889,7 @@ msgid ""
 "subsequent read operation to complete successfully.  Data integrity "
 "completion can reduce the number of disk operations that are required for "
 "applications that don't need the guarantees of file integrity completion."
-msgstr ""
+msgstr "B<O_SYNC> は、 同期 I/O でのI<ファイル>完全性完了を提供する。 つまり、 書き込み操作はデータとすべての関連メタデータを裏で利用されているハードウェアにフラッシュすることを意味する。 B<O_DSYNC> は、 同期 I/O でのI<データ>完全性完了を提供する。 つまり、 書き込み操作はデータを裏で利用されているハードウェアにフラッシュするが、 それ以降の読み出し操作が正常に完了するのに必要なメタデータの更新のみをフラッシュする。 データ完全性完了は、 ファイル完全性完了を必要としないアプリケーションで、 ディスク操作の数を減らすことができる。"
 
 #. type: Plain text
 #: build/C/man2/open.2:1165
@@ -7913,7 +7903,7 @@ msgid ""
 "is.  Thus, B<O_DSYNC> would only guarantee to flush updates to the file "
 "length metadata (whereas B<O_SYNC> would also always flush the last "
 "modification timestamp metadata)."
-msgstr ""
+msgstr "2 種類の完了の違いを理解するために、 ファイルメタデータの 2 つの要素、 ファイルの最終修正時刻 (I<st_mtime>) とファイル長、を考える。 すべての書き込み操作は最終修正時刻を更新するが、 ファイルの末尾にデータを追加する書き込み操作のみがファイル長を変更する。 最終修正時刻は、 読み出しが正常に完了するのに必要ではないが、 ファイル長は必要である。 したがって、 B<O_DSYNC> はファイル長のメタデータの更新がフラッシュされることだけを保証する (これに対して B<O_SYNC> では最終修正時刻のメタデータも常にフラッシュされる)。"
 
 #. type: Plain text
 #: build/C/man2/open.2:1177
@@ -7922,7 +7912,7 @@ msgid ""
 "().  However, when that flag was specified, most filesystems actually "
 "provided the equivalent of synchronized I/O I<data> integrity completion (i."
 "e., B<O_SYNC> was actually implemented as the equivalent of B<O_DSYNC>)."
-msgstr ""
+msgstr "Linux 2.6.33 より前では、 Linux は B<open>() では B<O_SYNC> フラグのみを実装していた。 しかしながら、 このフラグが指定された場合、 ほとんどのファイルシステムで提供されていたのは実際には同期 I/O でのI<データ>完全性完了と等価なものであった (つまり、 B<O_SYNC> は実際には B<O_DSYNC> と等価なものとして実装されていた)。"
 
 #. type: Plain text
 #: build/C/man2/open.2:1196
@@ -7933,7 +7923,7 @@ msgid ""
 "bit) flag value that includes the B<O_DSYNC> flag value.  This ensures that "
 "applications compiled against new headers get at least B<O_DSYNC> semantics "
 "on pre-2.6.33 kernels."
-msgstr ""
+msgstr "Linux 2.6.33 行こう では、 正しい B<O_SYNC> のサポートが提供されている。 しかしながら、 バイナリレベルの後方互換性を保証するため、 B<O_DSYNC> は以前の B<O_SYNC> と同じ値で定義されており、 B<O_SYNC> は B<O_DSYNC> フラグの値を含む新しい (2 ビットの) フラグ値として定義されている。 これにより、 新しいヘッダを使ってコンパイルされたアプリケーションで、 2.6.33 より前のカーネルで少なくとも B<O_DSYNC> の動作は同じになることが保証される。"
 
 #. type: SS
 #: build/C/man2/open.2:1196
@@ -8025,7 +8015,7 @@ msgid ""
 "B<utimensat>(2)  B<mkfifoat>(3), and B<scandirat>(3))  are supported for two "
 "reasons.  Here, the explanation is in terms of the B<openat>()  call, but "
 "the rationale is analogous for the other interfaces."
-msgstr ""
+msgstr "B<openat>() やディレクトリファイルディスクリプタを引き数を取る他のシステムコールやライブラリ関数 (B<faccessat>(2), B<fanotify_mark>(2), B<fchmodat>(2), B<fchownat>(2), B<fstatat>(2), B<futimesat>(2), B<linkat>(2), B<mkdirat>(2), B<mknodat>(2), B<name_to_handle_at>(2), B<readlinkat>(2), B<renameat>(2), B<symlinkat>(2), B<unlinkat>(2), B<utimensat>(2) B<mkfifoat>(3), B<scandirat>(3)) は二つの理由から用意されている。 ここでは、 B<openat> コールに関して説明するが、この基本原理は他のインターフェースでも同じである。"
 
 #. type: Plain text
 #: build/C/man2/open.2:1293
@@ -8037,7 +8027,7 @@ msgid ""
 "changed in parallel with the call to B<open>().  Such races can be avoided "
 "by opening a file descriptor for the target directory, and then specifying "
 "that file descriptor as the I<dirfd> argument of B<openat>()."
-msgstr ""
+msgstr "最初の理由として、 B<openat>() を使うと、 アプリケーションは、 カレントワーキングディレクトリ以外のディレクトリで B<open>() を使ってファイルをオープンする際に起こり得る競合条件を避けることができる。 これらの競合条件は、 B<open>() に渡されたディレクトリプレフィックスの構成要素が B<open>() の呼び出しと並行して変化する可能性があるという点に由来している。 このような競合条件は、 対象のディレクトリに対するファイルディスクリプタをオープンし、 それから B<openat>() の I<dirfd> 引き数としてそのファイルディスクリプタを指定することで、 避けることができる。"
 
 #. type: Plain text
 #: build/C/man2/open.2:1304
@@ -8046,7 +8036,7 @@ msgid ""
 "working directory\", via file descriptor(s) maintained by the application.  "
 "(This functionality can also be obtained by tricks based on the use of I</"
 "proc/self/fd/>dirfd, but less efficiently.)"
-msgstr ""
+msgstr "二つ目として、 B<openat>() を使うと、アプリケーションが管理するファイルディスクリプタにより、 スレッド単位の「カレントワーキングディレクトリ」を実装することができる (この機能は、 I</proc/self/fd/dirfd> を使った方法でも実現することができるが、 効率の面で落とる)。"
 
 #. type: SS
 #: build/C/man2/open.2:1304
diff --git a/release/man2/open.2 b/release/man2/open.2
index 51903a97..1c812bdf 100644
--- a/release/man2/open.2
+++ b/release/man2/open.2
@@ -155,7 +155,7 @@ flag) を 0 個以上「ビット単位の OR (bitwise\-or)」で 指定する
 は以下のリストのうち上記以外の残りのものである。 二種類のフラグの違いは、ファイル状態フラグの方はその内容を取得したり (場合によっては)
 変更したりできる点にある。詳細は \fBfcntl\fP(2) を参照。
 
-The full list of file creation flags and file status flags is as follows:
+すべてのファイル作成フラグとファイル状態フラグを以下のリストに示す。
 .TP 
 \fBO_APPEND\fP
 .\" For more background, see
@@ -175,25 +175,19 @@ The full list of file creation flags and file status flags is as follows:
 .TP 
 \fBO_CLOEXEC\fP (Linux 2.6.23 以降)
 .\" NOTE! several otehr man pages refer to this text
-Enable the close\-on\-exec flag for the new file descriptor.  Specifying this
-flag permits a program to avoid additional \fBfcntl\fP(2)  \fBF_SETFD\fP
-operations to set the \fBFD_CLOEXEC\fP flag.
+新しいファイルディスクリプタに対して close\-on\-exec フラグを有効にする。 このフラグを指定することで、 プログラムは
+\fBFD_CLOEXEC\fP フラグをセットするために \fBfcntl\fP(2) \fBF_SETFD\fP 操作を別途呼び出す必要がなくなる。
 
 .\" This flag fixes only one form of the race condition;
 .\" The race can also occur with, for example, descriptors
 .\" returned by accept(), pipe(), etc.
-Note that the use of this flag is essential in some multithreaded programs,
-because using a separate \fBfcntl\fP(2)  \fBF_SETFD\fP operation to set the
-\fBFD_CLOEXEC\fP flag does not suffice to avoid race conditions where one
-thread opens a file descriptor and attempts to set its close\-on\-exec flag
-using \fBfcntl\fP(2)  at the same time as another thread does a \fBfork\fP(2)
-plus \fBexecve\fP(2).  Depending on the order of execution, the race may lead
-to the file desriptor returned by \fBopen\fP()  being unintentionally leaked to
-the program executed by the child process created by \fBfork\fP(2).  (This kind
-of race is in principle possible for any system call that creates a file
-descriptor whose close\-on\-exec flag should be set, and various other Linux
-system calls provide an equivalent of the \fBO_CLOEXEC\fP flag to deal with
-this problem.)
+ある種のマルチスレッドのプログラムはこのフラグの使用は不可欠である点に注意すること。 なぜなら、個別に \fBFD_CLOEXEC\fP フラグを設定する
+\fBfcntl\fP(2) \fBF_SETFD\fP 操作を呼び出したとしても、あるスレッドがファイルディスクリプタを オープンするのと同時に別のスレッドが
+\fBfork\fP(2) と \fBexecve\fP(2) を実行するという競合条件を避けるのには十分ではないからである。
+実行の順序に依存して、この競合条件の結果、 \fBopen\fP() が返したファイルディスクリプタが \fBfork\fP(2)
+で作成された子プロセスにより実行されるプログラムに意図せず見えてしまう可能性がある。 (この種の競合は、 本質的に、 close\-on\-exec
+フラグをセットすべきファイルディスクリプタを作成するどのシステムコールでも起こり得るものであり、 他のいろいろな Linux
+システムコールでこの問題に対処するために \fBO_CLOEXEC\fP と同等の機能が提供されている。)
 .TP 
 \fBO_CREAT\fP
 .\" As at 2.6.25, bsdgroups is supported by ext2, ext3, ext4, and
@@ -269,13 +263,11 @@ this problem.)
 で追加された。
 .TP 
 \fBO_DSYNC\fP
-Write operations on the file will complete according to the requirements of
-synchronized I/O \fIdata\fP integrity completion.
+ファイルに対する書き込み操作は、同期 I/O の\fIデータ\fP完全性完了の要件に基づいて行われる。
 
-By the time \fBwrite\fP(2)  (and similar)  return, the output data has been
-transferred to the underlying hardware, along with any file metadata that
-would be required to retrieve that data (i.e., as though each \fBwrite\fP(2)
-was followed by a call to \fBfdatasync\fP(2)).  \fISee NOTES below\fP.
+\fBwrite\fP(2) (や同様のコール) が返るまでに、
+書き込まれたデータおよびデータを取得するのに必要なファイルメタデータが裏で利用されているハードウェアに転送される (つまり、\fBwrite\fP(2)
+の後に \fBfdatasync\fP(2) を呼び出したのと同じようになる)。 \fI下記の「注意」も参照のこと\fP。
 .TP 
 \fBO_EXCL\fP
 この呼び出しでファイルが作成されることを保証する。このフラグが \fBO_CREAT\fP と
@@ -382,29 +374,23 @@ PID を組み合わせた名前) を作成し、 \fBlink\fP(2)  を使用して
 \fIdirfd\fP 引数として使うことで、 そのシンボリックリンクに対して操作を行うことができる。
 .TP 
 \fBO_SYNC\fP
-Write operations on the file will complete according to the requirements of
-synchronized I/O \fIfile\fP integrity completion (by contrast with contrast
-with the synchronized I/O \fIdata\fP integrity completion provided by
-\fBO_DSYNC\fP.)
+ファイルに対する書き込み操作は、同期 I/O の\fIファイル\fP完全性完了の要件に基づいて行われる (これに対し \fBO_DSYNC\fP では同期 I/O
+の\fIデータ\fP完全性完了が提供される)。
 
-By the time \fBwrite\fP(2)  (and similar)  return, the output data and
-associated file metadata have been transferred to the underlying hardware
-(i.e., as though each \fBwrite\fP(2)  was followed by a call to \fBfsync\fP(2)).
-\fISee NOTES below\fP.
+\fBwrite\fP(2) (や同様のコール) が返るまでに、 書き込まれたデータと関連するファイルメタデータが裏で利用されているハードウェアに転送される
+(つまり、\fBwrite\fP(2) の後に \fBfsync\fP(2) を呼び出したのと同じようになる)。 \fI下記の「注意」も参照のこと\fP。
 .TP 
 \fBO_TMPFILE\fP (Linux 3.11 以降)
 .\" commit 60545d0d4610b02e55f65d141c95b18ccf855b6e
 .\" commit f4e0c30c191f87851c4a53454abb55ee276f4a7e
 .\" commit bb458c644a59dbba3a1fe59b27106c5e68e1c4bd
-Create an unnamed temporary file.  The \fIpathname\fP argument specifies a
-directory; an unnamed inode will be created in that directory's filesystem.
-Anything written to the resulting file will be lost when the last file
-descriptor is closed, unless the file is given a name.
+名前なしの一時ファイルを作成する。 \fIpathname\fP 引き数はディレクトリを指定する。 名前なしの inode
+がそのディレクトリが存在するファイルシステムに作成される。 そのファイルに名前を付与しない限り、 作成されたファイルに書き込まれた内容は、
+最後のファイルディスクリプタがクローズされる際に失われる。
 
-\fBO_TMPFILE\fP must be specified with one of \fBO_RDWR\fP or \fBO_WRONLY\fP and,
-optionally, \fBO_EXCL\fP.  If \fBO_EXCL\fP is not specified, then \fBlinkat\fP(2)
-can be used to link the temporary file into the filesystem, making it
-permanent, using code like the following:
+\fBO_TMPFILE\fP は必ず \fBO_RDWR\fP か \fBO_WRONLY\fP のいずれかと一緒に使わなければならない。 \fBO_EXCL\fP
+も指定することができる。 \fBO_EXCL\fP が指定されなかった場合、 \fBlinkat\fP(2)
+を使って、そのファイルシステムにこの一時ファイルへのリンクを作成し、ファイルを永続化することができる。 以下のコードのようにすればよい。
 
 .in +4n
 .nf
@@ -412,7 +398,7 @@ char path[PATH_MAX];
 fd = open("/path/to/dir", O_TMPFILE | O_RDWR,
                         S_IRUSR | S_IWUSR);
 
-/* File I/O on 'fd'... */
+/* 'fd' に対するファイル I/O ... */
 
 snprintf(path, PATH_MAX,  "/proc/self/fd/%d", fd);
 linkat(AT_FDCWD, path, AT_FDCWD, "/path/for/file",
@@ -420,36 +406,30 @@ linkat(AT_FDCWD, path, AT_FDCWD, "/path/for/file",
 .fi
 .in
 
-In this case, the \fBopen\fP()  \fImode\fP argument determines the file permission
-mode, as with \fBO_CREAT\fP.
+この場合、 \fBopen\fP() の \fImode\fP 引き数は \fBO_CREAT\fP と同様にファイルのアクセス許可モードの決定に使われる。
 
-Specifying \fBO_EXCL\fP in conjunction with \fBO_TMPFILE\fP prevents a temporary
-file from being linked into the filesystem in the above manner.  (Note that
-the meaning of \fBO_EXCL\fP in this case is different from the meaning of
-\fBO_EXCL\fP otherwise.)
+\fBO_TMPFILE\fP とともに \fBO_EXCL\fP を指定すると、
+一時ファイルに対して上記の方法でファイルシステムへのリンクを行うことができなくなる (この場合の \fBO_EXCL\fP の意味は他の場合の
+\fBO_EXCL\fP の意味とは異なる点に注意)。
 
 
 .\" Inspired by http://lwn.net/Articles/559147/
-There are two main use cases for \fBO_TMPFILE\fP:
+\fBO_TMPFILE\fP には主に二つの用途がある。
 .RS
 .IP * 3
-Improved \fBtmpfile\fP(3)  functionality: race\-free creation of temporary files
-that (1) are automatically deleted when closed; (2) can never be reached via
-any pathname; (3) are not subject to symlink attacks; and (4) do not require
-the caller to devise unique names.
+改善された \fBtmpfile\fP(3) の機能: (1) クローズ時に自動的に削除される、 (2) パス名では決して参照できない、 (3)
+シンボリックリンク攻撃ができない、 (4) 呼び出し元が一意な名前を考える必要がない、 という特長を持つ競合のない一時ファイルの作成。
 .IP *
-Creating a file that is initially invisible, which is then populated with
-data and adjusted to have appropriate filesystem attributes (\fBchown\fP(2),
-\fBchmod\fP(2), \fBfsetxattr\fP(2), etc.)  before being atomically linked into the
-filesystem in a fully formed state (using \fBlinkat\fP(2)  as described above).
+最初は見えないファイルを作成し、 それからデータを書き込んだり、適切なファイルシステム属性を持つように調整したり (\fBchown\fP(2),
+\fBchmod\fP(2), \fBfsetxattr\fP(2) など) した後、 準備が全て整った状態で (上述の \fBlinkat\fP(2) を使って)
+ファイルシステム内にアトミックにリンクを行う。
 .RE
 .IP
 .\" commit 99b6436bc29e4f10e4388c27a3e4810191cc4788
 .\" commit ab29743117f9f4c22ac44c13c1647fb24fb2bafe
-\fBO_TMPFILE\fP requires support by the underlying filesystem; only a subset of
-Linux filesystems provide that support.  In the initial implementation,
-support was provided in the ex2, ext3, ext4, UDF, Minix, and shmem
-filesystems.  XFS support was added in Linux 3.15.
+\fBO_TMPFILE\fP は、 裏で利用されるファイルシステムによるサポートが必要である。 一部の Linux
+ファイルシステムだけがこの機能をサポートしている。 最初の実装では、 ext2, ext3, ext4, UDF, Minix, shmem
+ファイルシステムがサポートしていた。 XFS でのサポートが Linux 3.15 で追加された。
 .TP 
 \fBO_TRUNC\fP
 ファイルが既に存在し、通常ファイルであり、 アクセスモードで書き込みが許可されている (つまり、 \fBO_RDWR\fP または \fBO_WRONLY\fP
@@ -473,7 +453,7 @@ filesystems.  XFS support was added in Linux 3.15.
 \fBopen\fP(), \fBopenat\fP(), \fBcreat\fP() は新しいファイルディスクリプタを返す。 エラーが発生した場合は \-1 を返す
 (その場合は \fIerrno\fP が適切に設定される)。
 .SH エラー
-\fBopen\fP(), \fBopenat\fP(), and \fBcreat\fP()  can fail with the following errors:
+\fBopen\fP(), \fBopenat\fP(), \fBcreat\fP() は以下のエラーで失敗する。
 .TP 
 \fBEACCES\fP
 ファイルに対する要求されたアクセスが許されていないか、 \fIpathname\fP のディレクトリ部分の何れかのディレクトリに検索許可がなかった。
@@ -510,16 +490,15 @@ filesystems.  XFS support was added in Linux 3.15.
 が設定されている)。
 .TP 
 \fBEISDIR\fP
-\fIpathname\fP refers to an existing directory, \fBO_TMPFILE\fP and one of
-\fBO_WRONLY\fP or \fBO_RDWR\fP were specified in \fIflags\fP, but this kernel version
-does not provide the \fBO_TMPFILE\fP functionality.
+\fIpathname\fP が存在するディレクトリを参照していて、 \fBO_TMPFILE\fP および \fBO_WRONLY\fP と \fBO_RDWR\fP
+の一方が \fIflags\fP に指定されていたが、 このカーネルバージョンでは \fBO_TMPFILE\fP 機能が提供されていない。
 .TP 
 \fBELOOP\fP
 \fIpathname\fP を解決する際に遭遇したシンボリックリンクが多過ぎる。
 .TP 
 \fBELOOP\fP
-\fIpathname\fP was a symbolic link, and \fIflags\fP specified \fBO_NOFOLLOW\fP but
-not \fBO_PATH\fP.
+\fIpathname\fP がシンボリックリンクで、 \fIflags\fP に \fBO_NOFOLLOW\fP が指定されたが、 \fBO_PATH\fP
+が指定されていなかった。
 .TP 
 \fBEMFILE\fP
 プロセスがオープンしているファイル数がすでに最大数に達している。
@@ -539,9 +518,8 @@ not \fBO_PATH\fP.
 (dangling) シンボリックリンクである。
 .TP 
 \fBENOENT\fP
-\fIpathname\fP refers to a nonexistent directory, \fBO_TMPFILE\fP and one of
-\fBO_WRONLY\fP or \fBO_RDWR\fP were specified in \fIflags\fP, but this kernel version
-does not provide the \fBO_TMPFILE\fP functionality.
+\fIpathname\fP が存在しないディレクトリを参照していて、 \fBO_TMPFILE\fP および \fBO_WRONLY\fP と \fBO_RDWR\fP
+の一方が \fIflags\fP に指定されていたが、 このカーネルバージョンでは \fBO_TMPFILE\fP 機能が提供されていない。
 .TP 
 \fBENOMEM\fP
 十分なカーネルメモリーがない。
@@ -602,16 +580,13 @@ POSIX.1\-2001 で規定されているエラーである。 2.6.24 より前の
 フラグ \fBO_DIRECT\fP, \fBO_NOATIME\fP, \fBO_PATH\fP, \fBO_TMPFILE\fP は Linux 特有のものである。
 これらのフラグの定義を得るためには \fB_GNU_SOURCE\fP を定義しなければならない。
 
-The \fBO_CLOEXEC\fP, \fBO_DIRECTORY\fP, and \fBO_NOFOLLOW\fP flags are not specified
-in POSIX.1\-2001, but are specified in POSIX.1\-2008.  Since glibc 2.12, one
-can obtain their definitions by defining either \fB_POSIX_C_SOURCE\fP with a
-value greater than or equal to 200809L or \fB_XOPEN_SOURCE\fP with a value
-greater than or equal to 700.  In glibc 2.11 and earlier, one obtains the
-definitions by defining \fB_GNU_SOURCE\fP.
+フラグ \fBO_CLOEXEC\fP, \fBO_DIRECTORY\fP, \fBO_NOFOLLOW\fP は POSIX.1\-2001 では規定されていないが、
+POSIX.1\-2008 では規定されている。 glibc 2.12 以降では、これらの定義を得るには、 \fB_POSIX_C_SOURCE\fP を
+200809L 以上の値で定義するか、 \fB_XOPEN_SOURCE\fP を 700 以上の値で定義する。 glibc 2.11 以前では、
+これらの定義を得るには \fB_GNU_SOURCE\fP を定義する。
 
-As noted in \fBfeature_test_macros\fP(7), feature test macros such as
-\fB_POSIX_C_SOURCE\fP, \fB_XOPEN_SOURCE\fP, and \fB_GNU_SOURCE\fP must be defined
-before including \fIany\fP header files.
+\fBfeature_test_macros\fP(7) に注意書きがあるように、 \fB_POSIX_C_SOURCE\fP, \fB_XOPEN_SOURCE\fP,
+\fB_GNU_SOURCE\fP などの機能検査マクロは\fIどの\fPヘッダーファイルをインクルードするより前に定義しなければならない。
 .SH 注意
 Linux では、 \fBO_NONBLOCK\fP フラグは、 open を実行したいが read または write を実行する意図は
 必ずしもないことを意味する。 これは \fBioctl\fP(2)  のためのファイルディスクリプタを取得するために、
@@ -635,48 +610,37 @@ Linux では、 \fBO_NONBLOCK\fP フラグは、 open を実行したいが read
 (それぞれ最終アクセス時刻、最終状態変更時刻、最終修正時刻である。 \fBstat\fP(2)  参照) が現在時刻に設定される。 さらに親ディレクトリの
 \fIst_ctime\fP と \fIst_mtime\fP も現在時刻に設定される。 それ以外の場合で、O_TRUNC フラグでファイルが修正されたときは、
 ファイルの \fIst_ctime\fP と \fIst_mtime\fP フィールドが現在時刻に設定される。
-.SS "Synchronized I/O"
-The POSIX.1\-2008 "synchronized I/O" option specifies different variants of
-synchronized I/O, and specifies the \fBopen\fP()  flags \fBO_SYNC\fP, \fBO_DSYNC\fP,
-and \fBO_RSYNC\fP for controlling the behavior.  Regardless of whether an
-implementation supports this option, it must at least support the use of
-\fBO_SYNC\fP for regular files.
-
-Linux implements \fBO_SYNC\fP and \fBO_DSYNC\fP, but not \fBO_RSYNC\fP.  (Somewhat
-incorrectly, glibc defines \fBO_RSYNC\fP to have the same value as \fBO_SYNC\fP.)
-
-\fBO_SYNC\fP provides synchronized I/O \fIfile\fP integrity completion, meaning
-write operations will flush data and all associated metadata to the
-underlying hardware.  \fBO_DSYNC\fP provides synchronized I/O \fIdata\fP integrity
-completion, meaning write operations will flush data to the underlying
-hardware, but will only flush metadata updates that are required to allow a
-subsequent read operation to complete successfully.  Data integrity
-completion can reduce the number of disk operations that are required for
-applications that don't need the guarantees of file integrity completion.
-
-To understand the difference between the the two types of completion,
-consider two pieces of file metadata: the file last modification timestamp
-(\fIst_mtime\fP)  and the file length.  All write operations will update the
-last file modification timestamp, but only writes that add data to the end
-of the file will change the file length.  The last modification timestamp is
-not needed to ensure that a read completes successfully, but the file length
-is.  Thus, \fBO_DSYNC\fP would only guarantee to flush updates to the file
-length metadata (whereas \fBO_SYNC\fP would also always flush the last
-modification timestamp metadata).
-
-Before Linux 2.6.33, Linux implemented only the \fBO_SYNC\fP flag for
-\fBopen\fP().  However, when that flag was specified, most filesystems actually
-provided the equivalent of synchronized I/O \fIdata\fP integrity completion
-(i.e., \fBO_SYNC\fP was actually implemented as the equivalent of \fBO_DSYNC\fP).
+.SS "同期 I/O"
+POSIX.1\-2008 の「同期 I/O」の選択肢として複数種類が規定されており、 動作を制御するために \fBopen\fP() フラグとして
+\fBO_SYNC\fP, \fBO_DSYNC\fP, \fBO_RSYNC\fP が規定されている。 この選択肢を実装がサポートしているかに関わらず、
+各実装では少なくとも通常のファイルに対して \fBO_SYNC\fP が利用できなければならない。
+
+Linux は \fBO_SYNC\fP と \fBO_DSYNC\fP を実装しているが、 \fBO_RSYNC\fP は実装していない (少し間違っているのだが、
+glibc では \fBO_RSYNC\fP が \fBO_SYNC\fP と同じ値で定義されている)。
+
+\fBO_SYNC\fP は、 同期 I/O での\fIファイル\fP完全性完了を提供する。 つまり、
+書き込み操作はデータとすべての関連メタデータを裏で利用されているハードウェアにフラッシュすることを意味する。 \fBO_DSYNC\fP は、 同期 I/O
+での\fIデータ\fP完全性完了を提供する。 つまり、 書き込み操作はデータを裏で利用されているハードウェアにフラッシュするが、
+それ以降の読み出し操作が正常に完了するのに必要なメタデータの更新のみをフラッシュする。 データ完全性完了は、
+ファイル完全性完了を必要としないアプリケーションで、 ディスク操作の数を減らすことができる。
+
+2 種類の完了の違いを理解するために、 ファイルメタデータの 2 つの要素、 ファイルの最終修正時刻 (\fIst_mtime\fP)
+とファイル長、を考える。 すべての書き込み操作は最終修正時刻を更新するが、 ファイルの末尾にデータを追加する書き込み操作のみがファイル長を変更する。
+最終修正時刻は、 読み出しが正常に完了するのに必要ではないが、 ファイル長は必要である。 したがって、 \fBO_DSYNC\fP
+はファイル長のメタデータの更新がフラッシュされることだけを保証する (これに対して \fBO_SYNC\fP
+では最終修正時刻のメタデータも常にフラッシュされる)。
+
+Linux 2.6.33 より前では、 Linux は \fBopen\fP() では \fBO_SYNC\fP フラグのみを実装していた。 しかしながら、
+このフラグが指定された場合、 ほとんどのファイルシステムで提供されていたのは実際には同期 I/O での\fIデータ\fP完全性完了と等価なものであった
+(つまり、 \fBO_SYNC\fP は実際には \fBO_DSYNC\fP と等価なものとして実装されていた)。
 
 .\"
 .\"
-Since Linux 2.6.33, proper \fBO_SYNC\fP support is provided.  However, to
-ensure backward binary compatibility, \fBO_DSYNC\fP was defined with the same
-value as the historical \fBO_SYNC\fP, and \fBO_SYNC\fP was defined as a new
-(two\-bit) flag value that includes the \fBO_DSYNC\fP flag value.  This ensures
-that applications compiled against new headers get at least \fBO_DSYNC\fP
-semantics on pre\-2.6.33 kernels.
+Linux 2.6.33 行こう では、 正しい \fBO_SYNC\fP のサポートが提供されている。 しかしながら、
+バイナリレベルの後方互換性を保証するため、 \fBO_DSYNC\fP は以前の \fBO_SYNC\fP と同じ値で定義されており、 \fBO_SYNC\fP は
+\fBO_DSYNC\fP フラグの値を含む新しい (2 ビットの) フラグ値として定義されている。 これにより、
+新しいヘッダを使ってコンパイルされたアプリケーションで、 2.6.33 より前のカーネルで少なくとも \fBO_DSYNC\fP
+の動作は同じになることが保証される。
 .SS NFS
 NFS を実現しているプロトコルには多くの不備があり、特に \fBO_SYNC\fP と \fBO_NDELAY\fP に影響する。
 
@@ -685,7 +649,7 @@ NFS を実現しているプロトコルには多くの不備があり、特に
 UID マッピングを使用している NFS ファイルシステムでは、 \fBopen\fP()  がファイルディスクリプタを返した場合でも \fBread\fP(2)
 が \fBEACCES\fP で拒否される場合がある。 これはクライアントがアクセス許可のチェックを行って \fBopen\fP()
 を実行するが、読み込みや書き込みの際には サーバーで UID マッピングが行われるためである。
-.SS "File access mode"
+.SS ファイルアクセスモード
 「アクセスモード」の値 \fBO_RDONLY\fP, \fBO_WRONLY\fP, \fBO_RDWR\fP は、 \fIflags\fP
 に指定できる他の値と違い、個々のビットを指定するものではなく、 これらの値は \fIflags\fP の下位 2 ビットを定義する。 \fBO_RDONLY\fP,
 \fBO_WRONLY\fP, \fBO_RDWR\fP はそれぞれ 0, 1, 2 に定義されている。 言い換えると、 \fBO_RDONLY |
@@ -702,30 +666,25 @@ Linux では、特別な、非標準なアクセスモードとして 3 (バイ
 このアクセスモードを指定すると、ファイルの読み出し/書き込み許可をチェックし、 読み出しにも書き込みにも使用できないディスクリプタを返す。
 この非標準のアクセスモードはいくつかの Linux ドライバで、デバイス固有の \fBioctl\fP(2)
 操作にのみ使用されるディスクリプタを返すために使われている。
-.SS "Rationale for openat() and other directory file descriptor APIs"
-\fBopenat\fP()  and the other system calls and library functions that take a
-directory file descriptor argument (i.e., \fBfaccessat\fP(2),
+.SS "openat() や他のディレクトリファイルディスクリプタ API の基本原理"
+\fBopenat\fP() やディレクトリファイルディスクリプタを引き数を取る他のシステムコールやライブラリ関数 (\fBfaccessat\fP(2),
 \fBfanotify_mark\fP(2), \fBfchmodat\fP(2), \fBfchownat\fP(2), \fBfstatat\fP(2),
 \fBfutimesat\fP(2), \fBlinkat\fP(2), \fBmkdirat\fP(2), \fBmknodat\fP(2),
 \fBname_to_handle_at\fP(2), \fBreadlinkat\fP(2), \fBrenameat\fP(2), \fBsymlinkat\fP(2),
-\fBunlinkat\fP(2), \fButimensat\fP(2)  \fBmkfifoat\fP(3), and \fBscandirat\fP(3))  are
-supported for two reasons.  Here, the explanation is in terms of the
-\fBopenat\fP()  call, but the rationale is analogous for the other interfaces.
-
-First, \fBopenat\fP()  allows an application to avoid race conditions that
-could occur when using \fBopen\fP()  to open files in directories other than
-the current working directory.  These race conditions result from the fact
-that some component of the directory prefix given to \fBopen\fP()  could be
-changed in parallel with the call to \fBopen\fP().  Such races can be avoided
-by opening a file descriptor for the target directory, and then specifying
-that file descriptor as the \fIdirfd\fP argument of \fBopenat\fP().
+\fBunlinkat\fP(2), \fButimensat\fP(2) \fBmkfifoat\fP(3), \fBscandirat\fP(3))
+は二つの理由から用意されている。 ここでは、 \fBopenat\fP コールに関して説明するが、この基本原理は他のインターフェースでも同じである。
+
+最初の理由として、 \fBopenat\fP() を使うと、 アプリケーションは、 カレントワーキングディレクトリ以外のディレクトリで \fBopen\fP()
+を使ってファイルをオープンする際に起こり得る競合条件を避けることができる。 これらの競合条件は、 \fBopen\fP()
+に渡されたディレクトリプレフィックスの構成要素が \fBopen\fP() の呼び出しと並行して変化する可能性があるという点に由来している。
+このような競合条件は、 対象のディレクトリに対するファイルディスクリプタをオープンし、 それから \fBopenat\fP() の \fIdirfd\fP
+引き数としてそのファイルディスクリプタを指定することで、 避けることができる。
 
 .\"
 .\"
-Second, \fBopenat\fP()  allows the implementation of a per\-thread "current
-working directory", via file descriptor(s) maintained by the application.
-(This functionality can also be obtained by tricks based on the use of
-\fI/proc/self/fd/\fPdirfd, but less efficiently.)
+二つ目として、 \fBopenat\fP() を使うと、アプリケーションが管理するファイルディスクリプタにより、
+スレッド単位の「カレントワーキングディレクトリ」を実装することができる (この機能は、 \fI/proc/self/fd/dirfd\fP
+を使った方法でも実現することができるが、 効率の面で落とる)。
 .SS O_DIRECT
 .LP
 \fBO_DIRECT\fP フラグを使用する場合、ユーザ空間バッファの長さやアドレス、 I/O
@@ -790,8 +749,8 @@ NFS で \fBO_DIRECT\fP を使った場合の動作はローカルのファイル
 現在のところ、 \fBopen\fP()  の呼び出し時に \fBO_ASYNC\fP を指定してシグナル駆動 I/O を有効にすることはできない。
 このフラグを有効にするには \fBfcntl\fP(2)  を使用すること。
 
-One must check for two different error codes, \fBEISDIR\fP and \fBENOENT\fP, when
-trying to determine whether the kernel supports \fBO_TMPFILE\fP functionality.
+カーネルが \fBO_TMPFILE\fP 機能をサポートしているかを判定する際に、 \fBEISDIR\fP と \fBENOENT\fP の 2
+つのエラーコードをチェックしなければならない。
 .SH 関連項目
 \fBchmod\fP(2), \fBchown\fP(2), \fBclose\fP(2), \fBdup\fP(2), \fBfcntl\fP(2), \fBlink\fP(2),
 \fBlseek\fP(2), \fBmknod\fP(2), \fBmmap\fP(2), \fBmount\fP(2), \fBopen_by_name_at\fP(2),
diff --git a/stats/stdio b/stats/stdio
index 2ab93c93..c07311f3 100644
--- a/stats/stdio
+++ b/stats/stdio
@@ -1,5 +1,4 @@
 # pagename,#complete,#remaining,#all
 fopencookie.3,65,33,98
-open.2,225,14,239
 open_by_handle_at.2,96,47,143
 symlink.7,48,23,71
diff --git a/translation_list b/translation_list
index b50c913c..b51b5686 100644
--- a/translation_list
+++ b/translation_list
@@ -234,7 +234,7 @@
 ï¼ :LDP man-pages:3.65:2008/12/03:oldolduname:2:uname:2:
 ï¼ :LDP man-pages:3.65:2014/03/19:oldstat:2:stat:2:
 ï¼ :LDP man-pages:3.65:2008/12/03:olduname:2:uname:2:
-☆:LDP man-pages:3.54=>3.65:2014/04/20:open:2:2013/10/14::amotoki@gmail.com:Akihiro MOTOKI:
+○:LDP man-pages:3.65:2014/04/20:open:2:2014/04/28::amotoki@gmail.com:Akihiro MOTOKI:
 ×:LDP man-pages:3.65:2014/03/24:open_by_handle_at:2:::::
 ï¼ :LDP man-pages:3.65:2014/04/20:openat:2:open:2:
 ○:LDP man-pages:3.65:2012/12/31:outb:2:2014/04/24::argrath@ub32.org:Kentaro Shirakata:
diff --git a/untrans.html b/untrans.html
index 2981d0cf..183e6adf 100644
--- a/untrans.html
+++ b/untrans.html
@@ -72,7 +72,6 @@
 <TR><TD>hpsa.4</TD><TD>23/57</TD><TD>59.65</TD></TR>
 <TR><TD ALIGN="center" COLSPAN=3 BGCOLOR="Yellow"><B>stdio</B></TD></TR>
 <TR><TD>fopencookie.3</TD><TD>33/98</TD><TD>66.33</TD></TR>
-<TR class="over80"><TD>open.2</TD><TD>14/239</TD><TD>94.14</TD></TR>
 <TR><TD>open_by_handle_at.2</TD><TD>47/143</TD><TD>67.13</TD></TR>
 <TR><TD>symlink.7</TD><TD>23/71</TD><TD>67.61</TD></TR>
 <TR><TD ALIGN="center" COLSPAN=3 BGCOLOR="Yellow"><B>stdlib</B></TD></TR>
@@ -82,6 +81,6 @@
 <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 54 pages</TD></TR>
+<TR><TD COLSPAN=3>Total 53 pages</TD></TR>
 </TABLE>
 </BODY></HTML>
-- 
2.11.0