.\" Updated 2013-05-06, Akihiro MOTOKI <amotoki@gmail.com>
.\" Updated 2013-08-16, Akihiro MOTOKI <amotoki@gmail.com>
.\"
-.TH OPEN 2 2014\-04\-06 Linux "Linux Programmer's Manual"
+.TH OPEN 2 2014\-05\-10 Linux "Linux Programmer's Manual"
.SH 名前
open, openat, creat \- ファイルのオープン、作成を行う
.SH 書式
を使うとこのデフォルトを変更することができる)。 ファイルオフセット
(file offset) はファイルの先頭に設定される (\fBlseek\fP(2) 参照)。
.PP
-\fBopen\fP() を呼び出すと、「オープンファイル記述」 \fI(open file description)\fP
-が作成される。ファイル記述とは、システム全体の オープン中のファイルのテーブルのエントリである。 このエントリは、ファイルオフセットとファイル状態フラグ
-(\fBfcntl\fP(2) \fBF_SETFL\fP 操作により変更可能) が保持する。 ファイルディスクリプタはこれらのエントリの一つへの参照である。
-この後で \fIpathname\fP が削除されたり、他のファイルを参照するように変更されたりしても、 この参照は影響を受けない。
-新しいオープンファイル記述は最初は他のどのプロセスとも 共有されていないが、 \fBfork\fP(2) で共有が起こる場合がある。
+A call to \fBopen\fP() creates a new \fIopen file description\fP, an entry in the
+system\-wide table of open files. (This object is variously also called an
+"open file object", a "file handle", an "open file table entry", or\(emin
+kernel\-developer parlance\(ema \fIstruct file\fP. The term "open file
+description" is used by POSIX.) The open file description records the file
+offset and the file status flags (see below). A file descriptor is a
+reference to an open file description; this reference is unaffected if
+\fIpathname\fP is subsequently removed or modified to refer to a different
+file. The new open file description is initially not shared with any other
+process, but sharing may arise via \fBfork\fP(2).
.PP
引き数 \fIflags\fP には、アクセスモード \fBO_RDONLY\fP, \fBO_WRONLY\fP, \fBO_RDWR\fP
のどれかひとつが入っていなければならない。 これらはそれぞれ読み込み専用、書き込み専用、読み書き用に ファイルをオープンすることを要求するものである。
は以下のリストのうち上記以外の残りのものである。 二種類のフラグの違いは、ファイル状態フラグの方はその内容を取得したり (場合によっては)
変更したりできる点にある。詳細は \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
に対しても使用できる。 さらに詳しい説明は \fBfcntl\fP(2) を参照すること。 下記の「バグ」も参照。
.TP
\fBO_CLOEXEC\fP (Linux 2.6.23 以降)
+.\" NOTE! several other man pages refer to this text
+新しいファイルディスクリプタに対して 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.
-新しいファイルディスクリプタに対して close\-on\-exec フラグを有効にする。 このフラグを指定することで、プログラムは
-\fBFD_CLOEXEC\fP フラグをセットするための \fBfcntl\fP(2) \fBF_SETFD\fP 操作を別途呼び出す必要がなくなる。
-また、ある種のマルチスレッドのプログラムはこのフラグの使用は 不可欠である。なぜなら、個別に \fBFD_CLOEXEC\fP フラグを設定する
-\fBfcntl\fP(2) \fBF_SETFD\fP 操作を呼び出したとしても、あるスレッドがファイルディスクリプタを オープンするのと同時に別のスレッドが
-\fBfork\fP(2) と \fBexecve\fP(2) を実行するという競合条件を避けるのには十分ではないからである。
+ある種のマルチスレッドのプログラムはこのフラグの使用は不可欠である点に注意すること。 なぜなら、個別に \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
.\" http://marc.theaimsgroup.com/?t=112748702800001&r=1&w=2
.\" [PATCH] open: O_DIRECTORY and O_CREAT together should fail
.\" O_DIRECTORY | O_CREAT causes O_DIRECTORY to be ignored.
-\fIpathname\fP がディレクトリでなければオープンは失敗する。 このフラグは Linux 特有であり、 \fBopendir\fP(3) が FIFO
+\fIpathname\fP がディレクトリでなければオープンは失敗する。 このフラグは、 \fBopendir\fP(3) が FIFO
やテープデバイスに対してコールされた場合の サービス不能 (denial\-of\-service) 攻撃を避けるために カーネル 2.1.126
で追加された。
.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 と
.IP *
\fBfcntl\fP(2) の \fBF_GETFL\fP 操作を使ったオープンされたファイルの状態フラグの取得。 返されるフラグには \fBO_PATH\fP
ビットが含まれる。
-
.IP *
-\fBopenat\fP(2) や他の "*at()" 系のシステムコールの \fIdirfd\fP 引数としてそのファイルディスクリプタを渡す。
+Passing the file descriptor as the \fIdirfd\fP argument of \fBopenat\fP(2) and
+the other "*at()" system calls. This includes \fBlinkat\fP(2) with
+\fBAT_EMPTY_PATH\fP (or via procfs using \fBAT_SYMLINK_FOLLOW\fP) even if the
+file is not a directory.
.IP *
そのファイルディスクリプタを別のプロセスに UNIX ドメインソケット経由で渡す。 (\fBunix\fP(7) の \fBSCM_RIGHTS\fP を参照)
.RE
\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
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",
.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
-.\" As at 3.13, there's support for at least ext2, ext3, ext4
-\fBO_TMPFILE\fP requires support by the underlying filesystem; only a subset of
-Linux filesystems provide that support.
+.\" commit 99b6436bc29e4f10e4388c27a3e4810191cc4788
+.\" commit ab29743117f9f4c22ac44c13c1647fb24fb2bafe
+\fBO_TMPFILE\fP は、 裏で利用されるファイルシステムによるサポートが必要である。 一部の Linux
+ファイルシステムだけがこの機能をサポートしている。 最初の実装では、 ext2, ext3, ext4, UDF, Minix, shmem
+ファイルシステムがサポートしていた。 XFS でのサポートが Linux 3.15 で追加された。
.TP
\fBO_TRUNC\fP
ファイルが既に存在し、通常ファイルであり、 アクセスモードで書き込みが許可されている (つまり、 \fBO_RDWR\fP または \fBO_WRONLY\fP
\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 のディレクトリ部分の何れかのディレクトリに検索許可がなかった。
\fIflags\fP に無効な値が入っている。
.TP
\fBEINVAL\fP
-\fBO_TMPFILE\fP was specified in \fIflags\fP, but neither \fBO_WRONLY\fP nor
-\fBO_RDWR\fP was specified.
+\fIflags\fP に \fBO_TMPFILE\fP が指定されたが、 \fBO_WRONLY\fP も \fBO_RDWR\fP も指定されていなかった。
.TP
\fBEISDIR\fP
\fIpathname\fP はディレクトリを参照しており、書き込み要求が含まれていた (つまり \fBO_WRONLY\fP または \fBO_RDWR\fP
が設定されている)。
.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
プロセスがオープンしているファイル数がすでに最大数に達している。
(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
十分なカーネルメモリーがない。
\fIpathname\fP がディレクトリでない。
.TP
\fBENXIO\fP
-\fBO_NONBLOCK\fP | \fBO_WRONLY\fP が設定されており、指定したファイルが FIFO で
-そのファイルを読み込みのためにオープンしているプロセスが存在しない。 または、ファイルがデバイススペシャルファイルで 対応するデバイスが存在しない。
+\fBO_NONBLOCK\fP | \fBO_WRONLY\fP が設定されており、指定したファイルが FIFO で そのファイルを読み込み用でオープンしている
+FIFO が存在しない。 または、ファイルがデバイススペシャルファイルで 対応するデバイスが存在しない。
.TP
\fBEOPNOTSUPP\fP
-The filesystem containing \fIpathname\fP does not support \fBO_TMPFILE\fP.
+\fIpathname\fP を含んでいるファイルシステムが \fBO_TMPFILE\fP をサポートしていない。
.TP
\fBEOVERFLOW\fP
.\" See http://bugzilla.kernel.org/show_bug.cgi?id=7253
\fIdirfd\fP が有効なファイルディスクリプタではない。
.TP
\fBENOTDIR\fP
-\fIpathname\fP が相対パスで、 \fIdirfd\fP がディレクトリ以外のファイルを参照しているファイルディスクリプタである。
+\fIpathname\fP が相対パス名で、 \fIdirfd\fP がディレクトリ以外のファイルを参照しているファイルディスクリプタである。
.SH バージョン
\fBopenat\fP() はカーネル 2.6.16 で Linux に追加された。 ライブラリによるサポートはバージョン 2.4 で glibc
に追加された。
\fBopenat\fP(): POSIX.1\-2008.
-The \fBO_DIRECT\fP, \fBO_NOATIME\fP, \fBO_PATH\fP, and \fBO_TMPFILE\fP flags are
-Linux\-specific. One must define \fB_GNU_SOURCE\fP to obtain their definitions.
+フラグ \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) のためのファイルディスクリプタを取得するために、
(それぞれ最終アクセス時刻、最終状態変更時刻、最終修正時刻である。 \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 に影響する。
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 |
このアクセスモードを指定すると、ファイルの読み出し/書き込み許可をチェックし、 読み出しにも書き込みにも使用できないディスクリプタを返す。
この非標準のアクセスモードはいくつかの 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
いくつかのファイルシステムでは、制限を確認するための独自のインタフェースが 提供されている。例えば、 \fBxfsctl\fP(3) の
\fBXFS_IOC_DIOINFO\fP 命令である。
.LP
-Linux 2.4 では、転送サイズ、 ユーザーバッファのアラインメント、ファイルオフセットは、
-ファイルシステムの論理ブロックサイズの倍数でなければならない。 Linux 2.6 では、512 バイトごとの境界に配置されていれば充分である。
+Under Linux 2.4, transfer sizes, and the alignment of the user buffer and
+the file offset must all be multiples of the logical block size of the
+filesystem. Since Linux 2.6.0, alignment to the logical block size of the
+underlying storage (typically 512 bytes) suffices. The logical block size
+can be determined using the \fBioctl\fP(2) \fBBLKSSZGET\fP operation or from the
+shell using the command:
+
+ blockdev \-\-getss
.LP
メモリバッファがプライベートマッピング (\fBmmap\fP(2) の \fBMAP_PRIVATE\fP
フラグで作成されたマッピング) の場合には、\fBO_DIRECT\fP I/O は
現在のところ、 \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),
+\fBlseek\fP(2), \fBmknod\fP(2), \fBmmap\fP(2), \fBmount\fP(2), \fBopen_by_handle_at\fP(2),
\fBread\fP(2), \fBsocket\fP(2), \fBstat\fP(2), \fBumask\fP(2), \fBunlink\fP(2),
\fBwrite\fP(2), \fBfopen\fP(3), \fBfifo\fP(7), \fBpath_resolution\fP(7), \fBsymlink\fP(7)
.SH この文書について
-この man ページは Linux \fIman\-pages\fP プロジェクトのリリース 3.64 の一部
+この man ページは Linux \fIman\-pages\fP プロジェクトのリリース 3.67 の一部
である。プロジェクトの説明とバグ報告に関する情報は
http://www.kernel.org/doc/man\-pages/ に書かれている。
OSDN Git Service
