X-Git-Url: http://git.osdn.net/view?a=blobdiff_plain;f=draft%2Fman2%2Faccess.2;h=e73bdfd951581e35c9e22b20f16507a56890914e;hb=c88a932e288e1688fce68cfdacb1b71884386ca0;hp=e63af0414fcec98e0bb42e59e93558bbce9f4cdb;hpb=0da9bbd99ec28dbd3b5d09ed1710bcbbb7bf8202;p=linuxjm%2FLDP_man-pages.git

diff --git a/draft/man2/access.2 b/draft/man2/access.2
index e63af041..e73bdfd9 100644
--- a/draft/man2/access.2
+++ b/draft/man2/access.2
@@ -69,7 +69,7 @@ access \- ファイルに対する実ユーザーでのアクセス権をチェ
 .fi
 .SH 説明
 \fBaccess\fP()  は、呼び出し元プロセスがファイル \fIpathname\fP にアクセスできるかどうかをチェックする。 \fIpathname\fP
-がシンボリック・リンクの場合、シンボリック・リンクは展開される。
+がシンボリックリンクの場合、シンボリックリンクは展開される。
 
 .\" F_OK is defined as 0 on every system that I know of.
 \fImode\fP はチェックを行うアクセス権を指定するもので、その値は \fBF_OK\fP、 もしくは \fBR_OK\fP, \fBW_OK\fP, \fBX_OK\fP の
@@ -106,7 +106,7 @@ permission) が得られなかった。 (\fBpath_resolution\fP(7)  も参照の
 \fIpathname\fP のディレクトリ部分が実際にはディレクトリでない。
 .TP 
 \fBEROFS\fP
-Write permission was requested for a file on a read\-only filesystem.
+読み込み専用 (read\-only) のファイルシステムに対して書き込み許可を 要求した。
 .PP
 \fBaccess\fP()  は以下の理由により失敗することがある。
 .TP 
@@ -153,14 +153,13 @@ POSIX.1\-2001 では、 呼び出し元プロセスが適切な特権を持っ
 ファイルはアクセス可能となる。 いずれかのディレクトリがアクセス不可の場合、 ファイル自身のアクセス許可に関わらず、 \fBaccess\fP()
 は失敗する。
 .PP
-アクセス・ビットのみがチェックされ、ファイルの種類や内容はチェックされない。 従って、ディレクトリが書き込み可能となった場合は、ディレクトリに
+アクセスビットのみがチェックされ、ファイルの種類や内容はチェックされない。 従って、ディレクトリが書き込み可能となった場合は、ディレクトリに
 ファイルを作成することが可能なことを意味するのであり、ディレクトリに ファイルとして書き込むことができるわけではない。 同様に DOS
 のファイルは「実行可能」と判断されるが、 \fBexecve\fP(2)  コールは失敗するだろう。
 .PP
-\fBaccess\fP()  may not work correctly on NFSv2 filesystems with UID mapping
-enabled, because UID mapping is done on the server and hidden from the
-client, which checks permissions.  (NFS versions 3 and higher perform the
-check on the server.)  Similar problems can occur to FUSE mounts.
+\fBaccess\fP() は、 UID マッピングを使用した NFSv2 ファイルシステムでは正常に機能しないかもしれない。なぜならば UID
+のマッピングはサーバーで 行なわれ、権利のチェックをするクライアントには見えないからである。 (NFS バージョン 3
+以降ではサーバー側でチェックが実行される。) 同様の問題は FUSE マウントでも起こり得る。
 .SH バグ
 .\" This behavior appears to have been an implementation accident.
 バージョン 2.4 (とそれ以前) のカーネルには、スーパーユーザでの \fBX_OK\fP のチェックの扱いに奇妙な点がある。 ディレクトリ以外のファイルで
@@ -168,9 +167,9 @@ check on the server.)  Similar problems can occur to FUSE mounts.
 \fBX_OK\fP だけが指定されたときだけであり \fImode\fP に \fBR_OK\fP や \fBW_OK\fP が一緒に指定された場合には
 \fBaccess\fP()  は 0 を返す。 (バージョン 2.6.3 以前の) 初期の 2.6 系のカーネルも 2.4 系のカーネルと同様の動作をする。
 
-In kernels before 2.6.20, \fBaccess\fP()  ignored the effect of the
-\fBMS_NOEXEC\fP flag if it was used to \fBmount\fP(2)  the underlying filesystem.
-Since kernel 2.6.20, \fBaccess\fP()  honors this flag.
+2.6.20 より前のカーネルでは、 ファイルが存在するファイルシステムを \fBmount\fP(2)  する際に指定された \fBMS_NOEXEC\fP
+フラグの効果を、 \fBaccess\fP()  は無視していた。 カーネル 2.6.20 以降では、 \fBaccess\fP()
+はこのフラグを考慮するようになっている。
 .SH 関連項目
 \fBchmod\fP(2), \fBchown\fP(2), \fBfaccessat\fP(2), \fBopen\fP(2), \fBsetgid\fP(2),
 \fBsetuid\fP(2), \fBstat\fP(2), \fBeauidaccess\fP(3), \fBcredentials\fP(7),