RFC1094 日本語訳
1094 NFS: Network File System Protocol specification. SunMicrosystems. March 1989. (Format: TXT=51454 bytes) (Also RFC1813) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Sun Microsystems, Inc. Request for Comments: 1094 March 1989
コメントを求めるワーキンググループサン・マイクロシステムズ・インクの要求をネットワークでつないでください: 1094 1989年3月
NFS: Network File System Protocol Specification
NFS: ネットワークファイルシステムプロトコル仕様
STATUS OF THIS MEMO
このメモの状態
This RFC describes a protocol that Sun Microsystems, Inc., and others are using. A new version of the protocol is under development, but others may benefit from the descriptions of the current protocol, and discussion of some of the design issues. Distribution of this memo is unlimited.
このRFCは、使用することでサン・マイクロシステムズ・インク、および他のものがそうであるプロトコルについて説明します。 プロトコルの新しいバージョンは開発中ですが、他のものは現在のプロトコルの記述、およびいくつかのデザイン問題の議論の利益を得るかもしれません。 このメモの分配は無制限です。
1. INTRODUCTION
1. 序論
The Sun Network Filesystem (NFS) protocol provides transparent remote access to shared files across networks. The NFS protocol is designed to be portable across different machines, operating systems, network architectures, and transport protocols. This portability is achieved through the use of Remote Procedure Call (RPC) primitives built on top of an eXternal Data Representation (XDR). Implementations already exist for a variety of machines, from personal computers to supercomputers.
Sun Network Filesystem(NFS)プロトコルはネットワークの向こう側に見え透いた遠隔アクセスを共有ファイルに供給します。 NFSプロトコルは、異なったマシン、オペレーティングシステム、ネットワークアーキテクチャ、およびトランスポート・プロトコルの向こう側に携帯用であるために設計されています。 この移植性はeXternal Data Representation(XDR)の上で築き上げられたRemote Procedure Call(RPC)基関数の使用で達成されます。 実装はさまざまなパーソナルコンピュータからスーパーコンピュータまでのマシンのために既に存在しています。
The supporting mount protocol allows the server to hand out remote access privileges to a restricted set of clients. It performs the operating system-specific functions that allow, for example, to attach remote directory trees to some local file system.
サポートしているマウントプロトコルで、サーバは制限されたセットのクライアントにリモートアクセス権を与えることができます。 それは例えばそれで何らかのローカルファイルシステムにリモートディレクトリツリーを取り付けるオペレーティングシステム具体的な機能を実行します。
1.1. Remote Procedure Call
1.1. 遠隔手続き呼び出し
Sun's Remote Procedure Call specification provides a procedure- oriented interface to remote services. Each server supplies a "program" that is a set of procedures. NFS is one such program. The combination of host address, program number, and procedure number specifies one remote procedure. A goal of NFS was to not require any specific level of reliability from its lower levels, so it could potentially be used on many underlying transport protocols, or even another remote procedure call implementation. For ease of discussion, the rest of this document will assume NFS is implemented on top of Sun RPC, described in RFC 1057, "RPC: Remote Procedure Call Protocol Specification".
SunのRemote Procedure Call仕様は手順指向のインタフェースをリモートサービスに提供します。 各サーバは1セットの手順である「プログラム」を供給します。 NFSはそのようなプログラムのひとりです。 ホスト・アドレス、プログラム番号、および手順番号の組み合わせは1つのリモート手順を指定します。 NFSの目標が下のレベルからどんな特定のレベルの信頼性も必要としないことであったので、多くの基本的なトランスポート・プロトコル、または別の遠隔手続き呼び出し実装でさえ潜在的にそれを使用できました。 議論の容易さのために、このドキュメントの残りが、NFSがRFC1057で説明されたSun RPCの上で実装されると仮定する、「RPC:」 「遠隔手続き呼び出しプロトコル仕様。」
1.2. External Data Representation
1.2. 外部データ表現
The eXternal Data Representation (XDR) standard provides a common way of representing a set of data types over a network. The NFS Protocol
eXternal Data Representation(XDR)規格はネットワークの上に1セットのデータ型を表す一般的な方法を提供します。 NFSプロトコル
Sun Microsystems, Inc. [Page 1] RFC 1094 NFS: Network File System March 1989
サン・マイクロシステムズ・インク[1ページ]RFC1094NFS: 1989年のネットワークファイルシステム行進
Specification is written using the RPC data description language. For more information, see RFC 1014, "XDR: External Data Representation Standard". Although automated RPC/XDR compilers exist to generate server and client "stubs", NFS does not require their use. Any software that provides equivalent functionality can be used, and if the encoding is exactly the same it can interoperate with other implementations of NFS.
仕様は、RPCデータ記述言語を使用することで書かれています。 詳しくは、RFC1014を見てください、「XDR:」 「外部データ表現規格。」 自動化されたRPC/XDRコンパイラはサーバとクライアント「スタッブ」を生成するために存在していますが、NFSは彼らの使用を必要としません。 同等な機能性を提供するどんなソフトウェアも使用できます、そして、コード化がまさに同じであるなら、それはNFSの他の実装で共同利用できます。
1.3. Stateless Servers
1.3. 状態がないサーバ
The NFS protocol was intended to be as stateless as possible. That is, a server should not need to maintain any protocol state information about any of its clients in order to function correctly. Stateless servers have a distinct advantage over stateful servers in the event of a failure. With stateless servers, a client need only retry a request until the server responds; it does not even need to know that the server has crashed, or the network temporarily went down. The client of a stateful server, on the other hand, needs to either detect a server failure and rebuild the server's state when it comes back up, or cause client operations to fail.
NFSプロトコルができるだけ状態がないことを意図しました。 すなわち、サーバは、正しく機能するようにクライアントのどれかのどんなプロトコル州の情報も保守する必要はないはずです。 状態がないサーバには、statefulサーバより異なった利点が失敗の場合、あります。 状態がないサーバで、サーバが反応するまで、クライアントは要求を再試行するだけでよいです。 それは、サーバがダウンしたか、またはネットワークが一時落ちたのを知る必要さえありません。 他方では、statefulサーバのクライアントは、サーバ失敗を検出して、来て戻るとき、サーバの状態を再建するか、またはクライアント操作が失敗することを引き起こす必要があります。
This may not sound like an important issue, but it affects the protocol in some unexpected ways. We feel that it may be worth a bit of extra complexity in the protocol to be able to write very simple servers that do not require fancy crash recovery. Note that even if a so-called "reliable" transport protocol such as TCP is used, the client must still be able to handle interruptions of service by re- opening connections when they time out. Thus, a stateless protocol may actually simplify the implementation.
これは切迫した課題のように聞こえないかもしれませんが、それはいくつかの予期していなかった方法でプロトコルに影響します。 私たちは、高級速成の回復を必要としない非常に簡単なサーバは書くことができるのがプロトコルにおける少しの付加的な複雑さの価値があるかもしれないと感じます。 TCPなどのいわゆる「信頼できる」トランスポート・プロトコルが使用されていても、クライアントが彼らであるときに接続を再開きタイムアウトでまだサービスの中断を扱うことができなければならないことに注意してください。 したがって、状態がないプロトコルは実際に実装を簡素化するかもしれません。
On the other hand, NFS deals with objects such as files and directories that inherently have state -- what good would a file be if it did not keep its contents intact? The goal was to not introduce any extra state in the protocol itself. Inherently stateful operations such as file or record locking, and remote execution, were implemented as separate services, not described in this document.
他方では、NFSは本来状態を持っているファイルやディレクトリなどのオブジェクトに対処します--コンテンツを完全に保たないなら、ファイルはどんな利益でしょうか? 目標はプロトコル自体で少しの付加的な状態も導入しないことでした。 本来、ファイルや記録的なロックや、リモート実行などのstateful操作は本書では説明されるのではなく、別々のサービスとして実装されました。
The basic way to simplify recovery was to make operations as "idempotent" as possible (so that they can potentially be repeated). Some operations in this version of the protocol did not attain this goal; luckily most of the operations (such as Read and Write) are idempotent. Also, most server failures occur between operations, not between the receipt of an operation and the response. Finally, although actual server failures may be rare, in complex networks, failures of any network, router, or bridge may be indistinguishable from a server failure.
回復を簡素化する基本的な方法は可能であるとしての「ベキ等元」として操作をする(潜在的にそれらを繰り返すことができるように)ことでした。 プロトコルのこのバージョンにおけるいくつかの操作はこの目標に達しませんでした。 運よく操作(ReadやWriteなどの)の大部分はベキ等元です。 また、ほとんどのサーバ失敗が操作の領収書と応答の間に起こるのではなく、操作の間に起こります。 最終的に、実際のサーバ失敗は複雑なネットワークでまれであるかもしれませんが、どんなネットワーク、ルータ、またはブリッジの失敗もサーバ失敗から区別がつかないかもしれません。
Sun Microsystems, Inc. [Page 2] RFC 1094 NFS: Network File System March 1989
サン・マイクロシステムズ・インク[2ページ]RFC1094NFS: 1989年のネットワークファイルシステム行進
2. NFS PROTOCOL DEFINITION
2. NFSプロトコル定義
Servers change over time, and so can the protocol that they use. RPC provides a version number with each RPC request. This RFC describes version two of the NFS protocol. Even in the second version, there are a few obsolete procedures and parameters, which will be removed in later versions. An RFC for version three of the NFS protocol is currently under preparation.
サーバは時間がたつにつれて変化します、そして、それらが使用するプロトコルもそうすることができます。 RPCはそれぞれのRPC要求をバージョン番号に提供します。 このRFCはNFSプロトコルのバージョンtwoについて説明します。 第2バージョンではさえ、いくつかの時代遅れの手順とパラメタがあります。(パラメタは後のバージョンで取り除かれるでしょう)。 現在、NFSプロトコルのバージョンthreeのためのRFCは準備中であります。
2.1. File System Model
2.1. ファイルのシステムモデル
NFS assumes a file system that is hierarchical, with directories as all but the bottom level of files. Each entry in a directory (file, directory, device, etc.) has a string name. Different operating systems may have restrictions on the depth of the tree or the names used, as well as using different syntax to represent the "pathname", which is the concatenation of all the "components" (directory and file names) in the name. A "file system" is a tree on a single server (usually a single disk or physical partition) with a specified "root". Some operating systems provide a "mount" operation to make all file systems appear as a single tree, while others maintain a "forest" of file systems. Files are unstructured streams of uninterpreted bytes. Version 3 of NFS uses slightly more general file system model.
NFSはファイルの下部レベル以外のすべてとしてディレクトリで階層的なファイルシステムを仮定します。 ディレクトリ(ファイル、ディレクトリ、デバイスなど)における各エントリーには、ストリング名があります。 異なったオペレーティングシステムで、名前で、すべての「コンポーネント」(ディレクトリとファイル名)の連結である「パス名」を表すのに異なった構文を使用することと同様に木か名前の深さにおける制限を使用するかもしれません。 「ファイルシステム」は指定された「根」があるただ一つのサーバ(通常単一のディスクか物理的な区分)の木です。 いくつかのオペレーティングシステムがすべてのファイルシステムを単一の木として現れさせるように「マウント」操作を提供します、他のものはファイルシステムの「森林」を維持しますが。ファイルは非解釈されたバイトの不統一なストリームです。 NFSのバージョン3はわずかに一般的なファイルのシステムモデルを使用します。
NFS looks up one component of a pathname at a time. It may not be obvious why it does not just take the whole pathname, traipse down the directories, and return a file handle when it is done. There are several good reasons not to do this. First, pathnames need separators between the directory components, and different operating systems use different separators. We could define a Network Standard Pathname Representation, but then every pathname would have to be parsed and converted at each end. Other issues are discussed in section 3, NFS Implementation Issues.
NFSは一度にパス名の1つの成分を見上げます。 完了している場合、それがなぜただ全体のパス名を取って、ディレクトリをぶらついて、ファイルハンドルを返さないかは、明白でないかもしれません。 これをしないように、いくつかのもっともな理由があります。 まず最初に、パス名はディレクトリの部品の間の分離符を必要とします、そして、異なったオペレーティングシステムは異なった分離符を使用します。 私たちがNetwork Standard Pathname Representationを定義できましたが、あらゆるパス名が、各端のときに分析されて、変換されなければならないでしょう。 NFS Implementation Issues、セクション3で他の問題について議論します。
Although files and directories are similar objects in many ways, different procedures are used to read directories and files. This provides a network standard format for representing directories. The same argument as above could have been used to justify a procedure that returns only one directory entry per call. The problem is efficiency. Directories can contain many entries, and a remote call to return each would be just too slow.
ファイルとディレクトリは様々な意味で同様のオブジェクトですが、異なった手順は、ディレクトリとファイルを読むのに用いられます。 これはネットワーク標準書式をディレクトリを表すのに提供します。 上の同じ議論は、1呼び出しあたり1つのディレクトリエントリだけを返す手順を正当化するのに使用されたかもしれません。 問題は効率です。 ディレクトリは多くのエントリーを含むことができます、そして、それぞれを返すというリモート要求はただ遅過ぎるでしょう。
2.2. Server Procedures
2.2. サーバ手順
The protocol definition is given as a set of procedures with arguments and results defined using the RPC language (XDR language extended with program, version, and procedure declarations). A brief
議論と結果が定義されている状態で、1セットの手順としてRPC言語を使用することでプロトコル定義を与えます(XDR言語はプログラム、バージョン、および手続きの宣言と共に広がりました)。 要約
Sun Microsystems, Inc. [Page 3] RFC 1094 NFS: Network File System March 1989
サン・マイクロシステムズ・インク[3ページ]RFC1094NFS: 1989年のネットワークファイルシステム行進
description of the function of each procedure should provide enough information to allow implementation. Section 2.3 describes the basic data types in more detail.
それぞれの手順の関数の記述は実装を許容できるくらいの情報を提供するべきです。 セクション2.3はさらに詳細に基本のデータ型について説明します。
All of the procedures in the NFS protocol are assumed to be synchronous. When a procedure returns to the client, the client can assume that the operation has completed and any data associated with the request is now on stable storage. For example, a client WRITE request may cause the server to update data blocks, filesystem information blocks (such as indirect blocks), and file attribute information (size and modify times). When the WRITE returns to the client, it can assume that the write is safe, even in case of a server crash, and it can discard the data written. This is a very important part of the statelessness of the server. If the server waited to flush data from remote requests, the client would have to save those requests so that it could resend them in case of a server crash.
NFSプロトコルの手順のすべてが同時であると思われます。 手順がクライアントに戻るとき、現在、安定貯蔵には缶が仮定する操作が完成したクライアントと要求に関連しているどんなデータもあります。 例えば、WRITEが要求するクライアントがサーバにデータ・ブロック、ファイル・システム情報ブロック(間接ブロックなどの)、およびファイル属性情報をアップデートさせるかもしれない、(サイズ、回を変更してください、) 書いてください。WRITEがクライアントに戻るとき、それを仮定できる、サーバの場合のさえ金庫はクラッシュであり、それは書かれたデータを捨てることができます。 これはサーバの国がないことの非常に重要な部分です。サーバが、リモート要求からデータを洗い流すのを待っているなら、クライアントは、サーバクラッシュの場合にそれらを再送できるように、それらの要求を保存しなければならないでしょうに。
/*
* Remote file service routines
*/
program NFS_PROGRAM {
version NFS_VERSION {
void
NFSPROC_NULL(void) = 0;
/**リモートファイルサービス・ルーチン*/プログラムNFS_PROGRAM、バージョンNFS_バージョン、NFSPROC_NULL(空の)=0を欠如させてください。
attrstat
NFSPROC_GETATTR(fhandle) = 1;
attrstat NFSPROC_GETATTR(fhandle)=1。
attrstat
NFSPROC_SETATTR(sattrargs) = 2;
attrstat NFSPROC_SETATTR(sattrargs)=2。
void
NFSPROC_ROOT(void) = 3;
NFSPROC_ROOT(空の)=3を欠如させてください。
diropres
NFSPROC_LOOKUP(diropargs) = 4;
diropres NFSPROC_LOOKUP(diropargs)=4。
readlinkres
NFSPROC_READLINK(fhandle) = 5;
readlinkres NFSPROC_READLINK(fhandle)=5。
readres
NFSPROC_READ(readargs) = 6;
readres NFSPROC_READ(readargs)=6。
void
NFSPROC_WRITECACHE(void) = 7;
NFSPROC_WRITECACHE(空の)=7を欠如させてください。
Sun Microsystems, Inc. [Page 4] RFC 1094 NFS: Network File System March 1989
サン・マイクロシステムズ・インク[4ページ]RFC1094NFS: 1989年のネットワークファイルシステム行進
attrstat
NFSPROC_WRITE(writeargs) = 8;
attrstat NFSPROC_WRITE(writeargs)=8。
diropres
NFSPROC_CREATE(createargs) = 9;
diropres NFSPROC_CREATE(createargs)=9。
stat
NFSPROC_REMOVE(diropargs) = 10;
スタットNFSPROC、_削除、(diropargs)=10。
stat
NFSPROC_RENAME(renameargs) = 11;
スタットNFSPROC_RENAME(renameargs)=11。
stat
NFSPROC_LINK(linkargs) = 12;
スタットNFSPROC_LINK(linkargs)=12。
stat
NFSPROC_SYMLINK(symlinkargs) = 13;
スタットNFSPROC_SYMLINK(symlinkargs)=13。
diropres
NFSPROC_MKDIR(createargs) = 14;
diropres NFSPROC_MKDIR(createargs)=14。
stat
NFSPROC_RMDIR(diropargs) = 15;
スタットNFSPROC_RMDIR(diropargs)=15。
readdirres
NFSPROC_READDIR(readdirargs) = 16;
readdirres NFSPROC_READDIR(readdirargs)=16。
statfsres
NFSPROC_STATFS(fhandle) = 17;
} = 2;
} = 100003;
statfsres NFSPROC_STATFS(fhandle)=17。 } = 2; } = 100003;
2.2.1. Do Nothing
2.2.1. 何もしないでください。
void
NFSPROC_NULL(void) = 0;
NFSPROC_NULL(空の)=0を欠如させてください。
This procedure does no work. It is made available in all RPC services to allow server response testing and timing.
この手順は全く仕事をしません。 サーバ応答にテストとタイミングを許容するためにそれをすべてのRPCサービスで利用可能にします。
2.2.2. Get File Attributes
2.2.2. ファイル属性を得てください。
attrstat
NFSPROC_GETATTR (fhandle) = 1;
attrstat NFSPROC_GETATTR(fhandle)=1。
If the reply status is NFS_OK, then the reply attributes contains the attributes for the file given by the input fhandle.
回答状態が_OKにNFSであるなら、回答属性は入力fhandleによって与えられたファイルのための属性を含んでいます。
Sun Microsystems, Inc. [Page 5] RFC 1094 NFS: Network File System March 1989
サン・マイクロシステムズ・インク[5ページ]RFC1094NFS: 1989年のネットワークファイルシステム行進
2.2.3. Set File Attributes
2.2.3. ファイル属性を設定してください。
struct sattrargs {
fhandle file;
sattr attributes;
};
fhandleがファイルする; sattr属性;struct sattrargs。
attrstat
NFSPROC_SETATTR (sattrargs) = 2;
attrstat NFSPROC_SETATTR(sattrargs)=2。
The "attributes" argument contains fields which are either -1 or are the new value for the attributes of "file". If the reply status is NFS_OK, then the reply attributes have the attributes of the file after the "SETATTR" operation has completed.
「属性」議論は「ファイル」の属性のためにどちらかの-1であるか新しい値である分野を含んでいます。 回答属性は回答状態がNFS_OKであるなら完成しました。"SETATTR"操作の後のファイルの属性は完成しました。
Notes: The use of -1 to indicate an unused field in "attributes" is changed in the next version of the protocol.
注意: プロトコルの次のバージョンで「属性」における未使用の分野を示す-1の使用を変えます。
2.2.4. Get Filesystem Root
2.2.4. ファイルシステム根を得てください。
void
NFSPROC_ROOT(void) = 3;
NFSPROC_ROOT(空の)=3を欠如させてください。
Obsolete. This procedure is no longer used because finding the root file handle of a filesystem requires moving pathnames between client and server. To do this right, we would have to define a network standard representation of pathnames. Instead, the function of looking up the root file handle is done by the MNTPROC_MNT procedure. (See Appendix A, "Mount Protocol Definition", for details).
時代遅れ。 ファイルシステムの根のファイルハンドルを見つけるのがクライアントとサーバの間の感動的なパス名を必要とするので、この手順はもう用いられません。何かこの正しいことをするために、私たちはパス名のネットワークの標準の表現を定義しなければならないでしょう。 代わりに、MNTPROC_MNT手順で根のファイルハンドルを見上げる機能をします。 (Appendix A、「山のプロトコル定義」を詳細に関して見ます。)
2.2.5. Look Up File Name
2.2.5. ファイル名を調べてください。
diropres
NFSPROC_LOOKUP(diropargs) = 4;
diropres NFSPROC_LOOKUP(diropargs)=4。
If the reply "status" is NFS_OK, then the reply "file" and reply "attributes" are the file handle and attributes for the file "name" in the directory given by "dir" in the argument.
回答「状態」が_OKにNFSであるなら、回答「ファイル」と回答「属性」は、議論で"dir"によって与えられたディレクトリの「名前」というファイルのためのファイルハンドルと属性です。
2.2.6. Read From Symbolic Link
2.2.6. シンボリックリンクから、読んでください。
union readlinkres switch (stat status) {
case NFS_OK:
path data;
default:
void;
};
組合readlinkresはケースNFS_OK: 経路データデフォルト: (空間)を切り換えます(スタット状態)。
Sun Microsystems, Inc. [Page 6] RFC 1094 NFS: Network File System March 1989
サン・マイクロシステムズ・インク[6ページ]RFC1094NFS: 1989年のネットワークファイルシステム行進
readlinkres
NFSPROC_READLINK(fhandle) = 5;
readlinkres NFSPROC_READLINK(fhandle)=5。
If "status" has the value NFS_OK, then the reply "data" is the data in the symbolic link given by the file referred to by the fhandle argument.
「状態」に値のNFS_OKがあるなら、fhandle議論で示されたファイルによって与えられたシンボリックリンクで回答「データ」はデータです。
Notes: Since NFS always parses pathnames on the client, the pathname in a symbolic link may mean something different (or be meaningless) on a different client or on the server if a different pathname syntax is used.
注意: NFSがクライアントの上でいつもパス名を分析するので、異なったパス名構文が使用されているなら、シンボリックリンクによるパス名は異なったクライアントの上、または、サーバの上で何か異なった(無意味であってください)ものを意味するかもしれません。
2.2.7. Read From File
2.2.7. ファイルから、読んでください。
struct readargs {
fhandle file;
unsigned offset;
unsigned count;
unsigned totalcount;
};
fhandleがファイルする; 未署名のオフセット; 未署名のカウント; 未署名のtotalcount;struct readargs。
union readres switch (stat status) {
case NFS_OK:
fattr attributes;
nfsdata data;
default:
void;
};
組合readresはケースNFS_OK: fattr属性; nfsdataデータデフォルト: (空間)を切り換えます(スタット状態)。
readres
NFSPROC_READ(readargs) = 6;
readres NFSPROC_READ(readargs)=6。
Returns up to "count" bytes of "data" from the file given by "file", starting at "offset" bytes from the beginning of the file. The first byte of the file is at offset zero. The file attributes after the read takes place are returned in "attributes".
「オフセット」のバイトでファイルの始まりから始まって、「ファイル」によって与えられたファイルからのバイトの「データ」を「数える」ために上がっているリターン。 ファイルの最初のバイトがオフセットゼロであります。 読みが行われた後に、「属性」でファイル属性を返します。
Notes: The argument "totalcount" is unused, and is removed in the next protocol revision.
注意: 議論"totalcount"を未使用であり、次のプロトコル改正で取り除きます。
2.2.8. Write to Cache
2.2.8. キャッシュに書いてください。
void
NFSPROC_WRITECACHE(void) = 7;
NFSPROC_WRITECACHE(空の)=7を欠如させてください。
To be used in the next protocol revision.
次のプロトコル改正に使用されるために。
Sun Microsystems, Inc. [Page 7] RFC 1094 NFS: Network File System March 1989
サン・マイクロシステムズ・インク[7ページ]RFC1094NFS: 1989年のネットワークファイルシステム行進
2.2.9. Write to File
2.2.9. ファイルするには、書いてください。
struct writeargs {
fhandle file;
unsigned beginoffset;
unsigned offset;
unsigned totalcount;
nfsdata data;
};
fhandleがファイルする; 未署名のbeginoffset; 未署名のオフセット; 未署名のtotalcount; nfsdataデータ;struct writeargs。
attrstat
NFSPROC_WRITE(writeargs) = 8;
attrstat NFSPROC_WRITE(writeargs)=8。
Writes "data" beginning "offset" bytes from the beginning of "file". The first byte of the file is at offset zero. If the reply "status" is NFS_OK, then the reply "attributes" contains the attributes of the file after the write has completed. The write operation is atomic. Data from this "WRITE" will not be mixed with data from another client's "WRITE".
「ファイル」の始まりから「データ」始めの「オフセット」バイトを書きます。 ファイルの最初のバイトがオフセットゼロであります。 書いてください。回答「属性」が回答「状態」が_OKにNFSであるなら後のファイルの属性を含んでいる、完成されて、持っています。 書いてください。操作は原子です。 この「書いてください」からのデータはクライアントの別のものからの「書いてください」というデータに混ぜられないでしょう。
Notes: The arguments "beginoffset" and "totalcount" are ignored and are removed in the next protocol revision.
注意: 議論の"beginoffset"と"totalcount"を無視して、次のプロトコル改正で取り除きます。
2.2.10. Create File
2.2.10. ファイルを作成してください。
struct createargs {
diropargs where;
sattr attributes;
};
struct createargsはどこ(sattr属性)をdiropargsするか。
diropres
NFSPROC_CREATE(createargs) = 9;
diropres NFSPROC_CREATE(createargs)=9。
The file "name" is created in the directory given by "dir". The initial attributes of the new file are given by "attributes". A reply "status" of NFS_OK indicates that the file was created, and reply "file" and reply "attributes" are its file handle and attributes. Any other reply "status" means that the operation failed and no file was created.
「名前」というファイルは"dir"によって与えられたディレクトリで作成されます。 「属性」は新しいファイルの初期の属性を与えます。 回答「ファイル」と回答「属性」は、そのNFS_OK回答「状態」は、ファイルが作成されたのを示して、ファイルハンドルと属性です。 いかなる他の回答「状態」も、操作が失敗したことを意味します、そして、ファイルは全く作成されませんでした。
Notes: This routine should pass an exclusive create flag, meaning "create the file only if it is not already there".
注意: このルーチンに合格するべきである、排他的である、「それが既にそこにない場合にだけ、ファイルを作成します」と意味して、旗を作成してください。
2.2.11. Remove File
2.2.11. ファイルを取り外してください。
stat
NFSPROC_REMOVE(diropargs) = 10;
スタットNFSPROC、_削除、(diropargs)=10。
Sun Microsystems, Inc. [Page 8] RFC 1094 NFS: Network File System March 1989
サン・マイクロシステムズ・インク[8ページ]RFC1094NFS: 1989年のネットワークファイルシステム行進
The file "name" is removed from the directory given by "dir". A reply of NFS_OK means the directory entry was removed.
「名前」というファイルは"dir"によって与えられたディレクトリから取り外されます。 NFS_OK回答は、ディレクトリエントリが取り除かれたことを意味します。
Notes: possibly non-idempotent operation.
注意: ことによると非ベキ等元操作。
2.2.12. Rename File
2.2.12. ファイルを改名してください。
struct renameargs {
diropargs from;
diropargs to;
};
struct renameargs、diropargsする、;、diropargsする、;、。
stat
NFSPROC_RENAME(renameargs) = 11;
スタットNFSPROC_RENAME(renameargs)=11。
The existing file "from.name" in the directory given by "from.dir" is renamed to "to.name" in the directory given by "to.dir". If the reply is NFS_OK, the file was renamed. The RENAME operation is atomic on the server; it cannot be interrupted in the middle.
"from.dir"によって与えられたディレクトリの既存ファイル"from.name"は"to.dir"によって与えられたディレクトリで"to.name"に改名されます。 回答が_OKにNFSであるなら、ファイルは改名されました。 RENAME操作はサーバで原子です。 中央でそれを中断できません。
Notes: possibly non-idempotent operation.
注意: ことによると非ベキ等元操作。
2.2.13. Create Link to File
2.2.13. ファイルするためにリンクを作成してください。
Procedure 12, Version 2.
手順12、バージョン2。
struct linkargs {
fhandle from;
diropargs to;
};
struct linkargs、fhandleする、;、diropargsする、;、。
stat
NFSPROC_LINK(linkargs) = 12;
スタットNFSPROC_LINK(linkargs)=12。
Creates the file "to.name" in the directory given by "to.dir", which is a hard link to the existing file given by "from". If the return value is NFS_OK, a link was created. Any other return value indicates an error, and the link was not created.
“from"によって与えられた既存ファイルへのハードリンクである"to.dir"によって与えられたディレクトリで"to.name"というファイルを作成します。 リターン値が_OKにNFSであるなら、リンクは作成されました。 いかなる他のリターン値も誤りを示します、そして、リンクは作成されませんでした。
A hard link should have the property that changes to either of the linked files are reflected in both files. When a hard link is made to a file, the attributes for the file should have a value for "nlink" that is one greater than the value before the link.
繋がっているファイルのどちらかへの変化は特性ですが、ハードリンクは両方のファイルで反射していた状態でそうするべきでした。 ハードリンクをファイルにするとき、ファイルのための属性で、1である"nlink"のための値はリンクの前では、値よりすばらしくなるべきです。
Notes: possibly non-idempotent operation.
注意: ことによると非ベキ等元操作。
Sun Microsystems, Inc. [Page 9] RFC 1094 NFS: Network File System March 1989
サン・マイクロシステムズ・インク[9ページ]RFC1094NFS: 1989年のネットワークファイルシステム行進
2.2.14. Create Symbolic Link
2.2.14. シンボリックリンクを作成してください。
struct symlinkargs {
diropargs from;
path to;
sattr attributes;
};
struct symlinkargs、diropargsする、;、経路、; sattr属性;、。
stat
NFSPROC_SYMLINK(symlinkargs) = 13;
スタットNFSPROC_SYMLINK(symlinkargs)=13。
Creates the file "from.name" with ftype NFLNK in the directory given by "from.dir". The new file contains the pathname "to" and has initial attributes given by "attributes". If the return value is NFS_OK, a link was created. Any other return value indicates an error, and the link was not created.
ftype NFLNKと共に"from.dir"によって与えられたディレクトリで"from.name"というファイルを作成します。 新しいファイルで、パス名“to"を入れてあて、「属性」は初期の属性を与えます。 リターン値が_OKにNFSであるなら、リンクは作成されました。 いかなる他のリターン値も誤りを示します、そして、リンクは作成されませんでした。
A symbolic link is a pointer to another file. The name given in "to" is not interpreted by the server, only stored in the newly created file. When the client references a file that is a symbolic link, the contents of the symbolic link are normally transparently reinterpreted as a pathname to substitute. A READLINK operation returns the data to the client for interpretation.
シンボリックリンクは別のファイルへの指針です。 負けという名前“to"は新たに作成されたファイルに保存されただけであるサーバによって解釈されません。 クライアントがシンボリックリンクであるファイルに参照をつけるとき、通常、シンボリックリンクの内容は、代理をするためにパス名として透過的に解釈し直されます。 READLINK操作は解釈のためにデータをクライアントに返します。
Notes: On UNIX servers the attributes are never used, since symbolic links always have mode 0777.
注意: Unixサーバーでは、シンボリックリンクにはモード0777がいつもあるので、属性は決して使用されません。
2.2.15. Create Directory
2.2.15. ディレクトリを作成してください。
diropres
NFSPROC_MKDIR (createargs) = 14;
diropres NFSPROC_MKDIR(createargs)=14。
The new directory "where.name" is created in the directory given by "where.dir". The initial attributes of the new directory are given by "attributes". A reply "status" of NFS_OK indicates that the new directory was created, and reply "file" and reply "attributes" are its file handle and attributes. Any other reply "status" means that the operation failed and no directory was created.
新しいディレクトリ"where.name"は"where.dir"によって与えられたディレクトリで作成されます。 「属性」は新しいディレクトリの初期の属性を与えます。 回答「ファイル」と回答「属性」は、そのNFS_OK回答「状態」は、新しいディレクトリが作成されたのを示して、ファイルハンドルと属性です。 いかなる他の回答「状態」も、操作が失敗したことを意味します、そして、ディレクトリは全く作成されませんでした。
Notes: possibly non-idempotent operation.
注意: ことによると非ベキ等元操作。
2.2.16. Remove Directory
2.2.16. ディレクトリを取り除いてください。
stat
NFSPROC_RMDIR(diropargs) = 15;
スタットNFSPROC_RMDIR(diropargs)=15。
Sun Microsystems, Inc. [Page 10] RFC 1094 NFS: Network File System March 1989
サン・マイクロシステムズ・インク[10ページ]RFC1094NFS: 1989年のネットワークファイルシステム行進
The existing empty directory "name" in the directory given by "dir" is removed. If the reply is NFS_OK, the directory was removed.
"dir"によって与えられたディレクトリの「名前」という既存の空のディレクトリは取り外されます。 回答が_OKにNFSであるなら、ディレクトリは取り外されました。
Notes: possibly non-idempotent operation.
注意: ことによると非ベキ等元操作。
2.2.17. Read From Directory
2.2.17. ディレクトリから、読んでください。
struct readdirargs {
fhandle dir;
nfscookie cookie;
unsigned count;
};
struct readdirargs、fhandle dir nfscookieクッキー; (未署名のカウント)。
struct entry {
unsigned fileid;
filename name;
nfscookie cookie;
entry *nextentry;
};
structエントリーの未署名のfileidファイル名名; nfscookieクッキー; (エントリー*nextentry)。
union readdirres switch (stat status) {
case NFS_OK:
struct {
entry *entries;
bool eof;
} readdirok;
default:
void;
};
組合readdirresはNFS_OK: ケースstructエントリー*エントリー; bool eof;readdirokデフォルト: (空間)を切り換えます(スタット状態)。
readdirres
NFSPROC_READDIR (readdirargs) = 16;
readdirres NFSPROC_READDIR(readdirargs)=16。
Returns a variable number of directory entries, with a total size of up to "count" bytes, from the directory given by "dir". If the returned value of "status" is NFS_OK, then it is followed by a variable number of "entry"s. Each "entry" contains a "fileid" which consists of a unique number to identify the file within a filesystem, the "name" of the file, and a "cookie" which is an opaque pointer to the next entry in the directory. The cookie is used in the next READDIR call to get more entries starting at a given point in the directory. The special cookie zero (all bits zero) can be used to get the entries starting at the beginning of the directory. The "fileid" field should be the same number as the "fileid" in the the attributes of the file. (See section "2.3.5. fattr" under "Basic Data Types".) The "eof" flag has a value of TRUE if there are no more entries in the directory.
バイトを「数える」ために上の総サイズと共に"dir"によって与えられたディレクトリから可変数のディレクトリエントリーを返します。 「状態」の戻り値が_OKにNFSであるなら、可変数の「エントリー」sがそれのあとに続いています。 各「エントリー」はディレクトリにおける次のエントリーにファイルシステム、ファイルの「名前」、および不透明な指針である「クッキー」の中でファイルを特定するユニークな数から成る"fileid"を含んでいます。 クッキーは、より多くのエントリーをディレクトリで与えられたポイントで始めさせるという次のREADDIR要求に使用されます。 エントリーをディレクトリの始めに始めさせるのに、特別なクッキーゼロ(ビットが合っているゼロすべて)を使用できます。 "fileid"分野はファイルの属性における"fileid"と同じ数であるべきです。 (「基礎データタイプ」の下で「2.3.5fattr」というセクションを見てください。) "eof"旗には、ディレクトリにそれ以上のエントリーが全くなければ、TRUEの値があります。
Sun Microsystems, Inc. [Page 11] RFC 1094 NFS: Network File System March 1989
サン・マイクロシステムズ・インク[11ページ]RFC1094NFS: 1989年のネットワークファイルシステム行進
2.2.18. Get Filesystem Attributes
2.2.18. ファイルシステム属性を得てください。
union statfsres (stat status) {
case NFS_OK:
struct {
unsigned tsize;
unsigned bsize;
unsigned blocks;
unsigned bfree;
unsigned bavail;
} info;
default:
void;
};
組合statfsres(スタット状態)はNFS_OK: struct未署名のtsize; 未署名のbsize; 未署名のブロック; 未署名のbfree; 未署名のbavail;インフォメーションデフォルト: (空間)をケースに入れます。
statfsres
NFSPROC_STATFS(fhandle) = 17;
statfsres NFSPROC_STATFS(fhandle)=17。
If the reply "status" is NFS_OK, then the reply "info" gives the attributes for the filesystem that contains file referred to by the input fhandle. The attribute fields contain the following values:
回答「状態」が_OKにNFSであるなら、回答「インフォメーション」は入力fhandleによって示されたファイルを含むファイルシステムのために属性を与えます。 属性分野は以下の値を含んでいます:
tsize The optimum transfer size of the server in bytes. This is
the number of bytes the server would like to have in the
data part of READ and WRITE requests.
バイトで表現されるサーバの最適な転送サイズのtsize。 これはサーバがREADとWRITE要求のデータ部分で必要とするバイト数です。
bsize The block size in bytes of the filesystem.
bsize、ファイルシステムのバイトで表現されるブロック・サイズ。
blocks The total number of "bsize" blocks on the filesystem.
"bsize"の総数がファイルシステムで妨げるブロック。
bfree The number of free "bsize" blocks on the filesystem.
自由な"bsize"の数がファイルシステムで妨げるbfree。
bavail The number of "bsize" blocks available to non-privileged
users.
非特権ユーザにとって、有効な数の"bsize"bavailブロック。
Notes: This call does not work well if a filesystem has variable size blocks.
注意: ファイルシステムに可変サイズブロックがあるなら、この呼び出しはうまくいきません。
2.3. Basic Data Types
2.3. 基本のデータ型
The following XDR definitions are basic structures and types used in other structures described further on.
以下のXDR定義は基本的な構造であり、さらに説明された非重要構造の中古であるタイプはオンです。
2.3.1. stat
2.3.1. スタット
enum stat {
NFS_OK = 0,
NFSERR_PERM=1,
enumスタット、NFS_OKは0、NFSERR_PERM=1と等しいです。
Sun Microsystems, Inc. [Page 12] RFC 1094 NFS: Network File System March 1989
サン・マイクロシステムズ・インク[12ページ]RFC1094NFS: 1989年のネットワークファイルシステム行進
NFSERR_NOENT=2,
NFSERR_IO=5,
NFSERR_NXIO=6,
NFSERR_ACCES=13,
NFSERR_EXIST=17,
NFSERR_NODEV=19,
NFSERR_NOTDIR=20,
NFSERR_ISDIR=21,
NFSERR_FBIG=27,
NFSERR_NOSPC=28,
NFSERR_ROFS=30,
NFSERR_NAMETOOLONG=63,
NFSERR_NOTEMPTY=66,
NFSERR_DQUOT=69,
NFSERR_STALE=70,
NFSERR_WFLUSH=99
};
NFSERR_NOENT=2、NFSERR_イーオー=5、NFSERR_NXIO=6、NFSERR_ACCES=13、NFSERR_が存在している、=17、NFSERR_NODEV=19、NFSERR_NOTDIR=20、NFSERR_ISDIR=21、NFSERR_FBIG=27、NFSERR_NOSPC=28、NFSERR_ROFS=30、NFSERR_NAMETOOLONG=63、NFSERR_NOTEMPTY=66、NFSERR_DQUOT=69、_が聞き古したであるNFSERR=70、NFSERR_WFLUSH=99、。
The "stat" type is returned with every procedure's results. A value of NFS_OK indicates that the call completed successfully and the results are valid. The other values indicate some kind of error occurred on the server side during the servicing of the procedure. The error values are derived from UNIX error numbers.
「スタット」タイプがともに帰られる、あらゆる、プロシージャの結果。 NFS_OK値は、首尾よく終了する呼び出しと結果が有効であることを示します。 他の値は、ある種の誤りが手順の整備点検の間サーバ側に発生したのを示します。 UNIXエラー番号から誤り値を得ます。
NFSERR_PERM
Not owner. The caller does not have correct ownership to perform
the requested operation.
NFSERR_PERM Not所有者。 訪問者には、要求された操作を実行する正しい所有権がありません。
NFSERR_NOENT
No such file or directory. The file or directory specified does
not exist.
そのようなものがファイルするNFSERR_NOENTノーかディレクトリ。 指定されたファイルかディレクトリが存在していません。
NFSERR_IO
Some sort of hard error occurred when the operation was in
progress. This could be a disk error, for example.
操作が進行していたとき、IO Someが分類する困難な誤りのNFSERR_は現れました。 例えば、これはディスク誤りであるかもしれません。
NFSERR_NXIO
No such device or address.
NFSERR_NXIOのいいえのそのようなデバイスかアドレス。
NFSERR_ACCES
Permission denied. The caller does not have the correct
permission to perform the requested operation.
ACCES Permissionが否定したNFSERR_。 訪問者には、要求された操作を実行する正しい許可がありません。
NFSERR_EXIST
File exists. The file specified already exists.
NFSERR_EXIST Fileは存在しています。 指定されたファイルは既に存在しています。
NFSERR_NODEV
No such device.
NFSERR_NODEVのいいえのそのようなデバイス。
Sun Microsystems, Inc. [Page 13] RFC 1094 NFS: Network File System March 1989
サン・マイクロシステムズ・インク[13ページ]RFC1094NFS: 1989年のネットワークファイルシステム行進
NFSERR_NOTDIR
Not a directory. The caller specified a non-directory in a
directory operation.
NFSERR_NOTDIR Not aディレクトリ。 訪問者はディレクトリ操作で非ディレクトリを指定しました。
NFSERR_ISDIR
Is a directory. The caller specified a directory in a non-
directory operation.
NFSERR_ISDIR Is aディレクトリ。 訪問者は非ディレクトリ操作でディレクトリを指定しました。
NFSERR_FBIG
File too large. The operation caused a file to grow beyond the
server's limit.
NFSERR_FBIG File、も大きいです。 操作で、ファイルはサーバの限界を超えたところまで成長しました。
NFSERR_NOSPC
No space left on device. The operation caused the server's
filesystem to reach its limit.
NFSERR_NOSPCいいえスペースはデバイスでいなくなりました。 操作で、サーバのファイルシステムは限界に達しました。
NFSERR_ROFS
Read-only filesystem. Write attempted on a read-only filesystem.
NFSERR_ROFS Read唯一のファイルシステム。 書き込み禁止ファイルシステムで試みられた状態で、書いてください。
NFSERR_NAMETOOLONG
File name too long. The file name in an operation was too long.
NAMETOOLONG Fileがあまりに長い間命名するNFSERR_。 稼働中であるファイル名は長過ぎました。
NFSERR_NOTEMPTY
Directory not empty. Attempted to remove a directory that was not
empty.
NFSERR_NOTEMPTYディレクトリは空になりません。 空でなかったディレクトリを取り外すのを試みました。
NFSERR_DQUOT
Disk quota exceeded. The client's disk quota on the server has
been exceeded.
DQUOT Disk割当てが超えていたNFSERR_。 サーバに関するクライアントのディスク・クオータは超えられています。
NFSERR_STALE
The "fhandle" given in the arguments was invalid. That is, the
file referred to by that file handle no longer exists, or access
to it has been revoked.
議論におけるNFSERR_STALE"fhandle"当然のことは無効でした。 すなわち、そのファイルハンドルによって示されたファイルがもう存在していないか、またはそれへのアクセスは取り消されました。
NFSERR_WFLUSH
The server's write cache used in the "WRITECACHE" call got flushed
to disk.
サーバのものが呼ぶと"WRITECACHE"で使用されるキャッシュに書くNFSERR_WFLUSHはディスクに洗い流されました。
Sun Microsystems, Inc. [Page 14] RFC 1094 NFS: Network File System March 1989
サン・マイクロシステムズ・インク[14ページ]RFC1094NFS: 1989年のネットワークファイルシステム行進
2.3.2. ftype
2.3.2. ftype
enum ftype {
NFNON = 0,
NFREG = 1,
NFDIR = 2,
NFBLK = 3,
NFCHR = 4,
NFLNK = 5
};
enum ftype、NFNON=0、NFREG=1、NFDIR=2、NFBLKは3、NFCHR=4と等しいです、NFLNK=5。
The enumeration "ftype" gives the type of a file. The type NFNON
indicates a non-file, NFREG is a regular file, NFDIR is a
directory, NFBLK is a block-special device, NFCHR is a character-
special device, and NFLNK is a symbolic link.
列挙"ftype"はファイルのタイプに与えます。 タイプNFNONは、非ファイルであり、NFREGが通常のファイルであることを示します、そして、NFDIRはディレクトリです、そして、NFBLKはブロック特別なデバイスです、そして、NFCHRはキャラクタの特別なデバイスです、そして、NFLNKはシンボリックリンクです。
2.3.3. fhandle
2.3.3. fhandle
typedef opaque fhandle[FHSIZE];
typedefの不透明なfhandle[FHSIZE]。
The "fhandle" is the file handle passed between the server and the
client. All file operations are done using file handles to refer
to a file or directory. The file handle can contain whatever
information the server needs to distinguish an individual file.
"fhandle"はサーバとクライアントの間で渡されたファイルハンドルです。 すべてのファイル操作がファイルかディレクトリを参照するのにファイルハンドルを使用し終わっています。 ファイルハンドルはサーバが個々のファイルを区別するために必要とするどんな情報も含むことができます。
2.3.4. timeval
2.3.4. timeval
struct timeval {
unsigned int seconds;
unsigned int useconds;
};
未署名のintが後援する; 未署名のint useconds;struct timeval。
The "timeval" structure is the number of seconds and microseconds
since midnight January 1, 1970, Greenwich Mean Time. It is used
to pass time and date information.
1970年1月1日真夜中、グリニッジ標準時以来、"timeval"構造は、秒数とマイクロセカンドです。 それは、日時の情報を通過するのに使用されます。
2.3.5. fattr
2.3.5. fattr
struct fattr {
ftype type;
unsigned int mode;
unsigned int nlink;
unsigned int uid;
unsigned int gid;
unsigned int size;
unsigned int blocksize;
unsigned int rdev;
unsigned int blocks;
struct fattr、ftypeタイプ; 未署名のintモード; 未署名のint nlink; 未署名のint uid; 未署名のintヒツジ暈倒病; 未署名のintサイズ; 未署名のint blocksize; 未署名のint rdev; 未署名のintブロック。
Sun Microsystems, Inc. [Page 15] RFC 1094 NFS: Network File System March 1989
サン・マイクロシステムズ・インク[15ページ]RFC1094NFS: 1989年のネットワークファイルシステム行進
unsigned int fsid;
unsigned int fileid;
timeval atime;
timeval mtime;
timeval ctime;
};
未署名のint fsid。 未署名のint fileid。 timeval atime。 timeval mtime。 timeval ctime。 };
The "fattr" structure contains the attributes of a file; "type" is
the type of the file; "nlink" is the number of hard links to the
file (the number of different names for the same file); "uid" is
the user identification number of the owner of the file; "gid" is
the group identification number of the group of the file; "size"
is the size in bytes of the file; "blocksize" is the size in bytes
of a block of the file; "rdev" is the device number of the file if
it is type NFCHR or NFBLK; "blocks" is the number of blocks the
file takes up on disk; "fsid" is the file system identifier for
the filesystem containing the file; "fileid" is a number that
uniquely identifies the file within its filesystem; "atime" is the
time when the file was last accessed for either read or write;
"mtime" is the time when the file data was last modified
(written); and "ctime" is the time when the status of the file was
last changed. Writing to the file also changes "ctime" if the
size of the file changes.
"fattr"構造はファイルの属性を含んでいます。 「タイプ」はファイルのタイプです。 "nlink"はファイル(同じファイルのための異なった名前の数)へのハードリンクの数です。 "uid"はファイルの所有者のユーザ登録名番号です。 「ヒツジ暈倒病」はファイルのグループに関するグループ識別番号です。 「サイズ」はファイルのバイトで表現されるサイズです。 "blocksizeする"はファイルの1ブロックのバイトで表現されるサイズです。 それがタイプNFCHRかNFBLKであるなら、"rdev"はファイルの装置番号です。 「ブロック」はファイルがディスクの上で取るブロックの数です。 "fsid"はファイルを含むファイルシステムのためのファイルシステム識別子です。 "fileid"はファイルシステムの中で唯一ファイルを特定する数です。 "atime"はいつの間、ファイルがアクセスされていた状態で持続することであったかが読むか、または書く時です。 "mtime"はファイルデータが最後に変更された(書かれています)時です。 そして、"ctime"はファイルの状態が最後に変えられた時です。 また、ファイルのサイズが変化するなら、ファイルに書くのは"ctime"を変えます。
"Mode" is the access mode encoded as a set of bits. Notice that
the file type is specified both in the mode bits and in the file
type. This is really a bug in the protocol and will be fixed in
future versions. The descriptions given below specify the bit
positions using octal numbers.
「モード」は1セットのビットとしてコード化されたアクセス・モードです。 ファイルの種類がモードビットとファイルの種類で指定されるのに注意してください。 これは、本当にプロトコルのバグであり、将来のバージョンで修理されるでしょう。 以下に与えられた記述は、8進数を使用することでビット位置を指定します。
0040000 This is a directory; "type" field should be NFDIR.
0020000 This is a character special file; "type" field should
be NFCHR.
0060000 This is a block special file; "type" field should be
NFBLK.
0100000 This is a regular file; "type" field should be NFREG.
0120000 This is a symbolic link file; "type" field should be
NFLNK.
0140000 This is a named socket; "type" field should be NFNON.
0004000 Set user id on execution.
0002000 Set group id on execution.
0001000 Save swapped text even after use.
0000400 Read permission for owner.
0000200 Write permission for owner.
0000100 Execute and search permission for owner.
0000040 Read permission for group.
0000020 Write permission for group.
0000010 Execute and search permission for group.
0040000 これはディレクトリです。 「タイプ」分野はNFDIRであるべきです。 0020000 これはキャラクタの特別なファイルです。 「タイプ」分野はNFCHRであるべきです。 0060000 これはブロックの特別なファイルです。 「タイプ」分野はNFBLKであるべきです。 0100000 これは通常のファイルです。 「タイプ」分野はNFREGであるべきです。 0120000 これはシンボリックリンクファイルです。 「タイプ」分野はNFLNKであるべきです。 0140000 これは命名されたソケットです。 「タイプ」分野はNFNONであるべきです。 0004000はユーザイドを実行に設定します。 0002000はグループイドを実行に設定します。 0001000は使用の後にさえ交換されたテキストを保存します。 0000400は所有者のために許可を読みます。 0000200は所有者のために許可を書きます。 0000100は、所有者のために許可を実行して、捜します。 0000040はグループのために許可を読みます。 0000020はグループのために許可を書きます。 0000010は、グループのために許可を実行して、捜します。
Sun Microsystems, Inc. [Page 16] RFC 1094 NFS: Network File System March 1989
サン・マイクロシステムズ・インク[16ページ]RFC1094NFS: 1989年のネットワークファイルシステム行進
0000004 Read permission for others.
0000002 Write permission for others.
0000001 Execute and search permission for others.
0000004は他のもののために許可を読みます。 0000002は他のもののために許可を書きます。 0000001は、他のもののために許可を実行して、捜します。
Notes: The bits are the same as the mode bits returned by the
stat(2) system call in UNIX. The file type is specified both in
the mode bits and in the file type. This is fixed in future
versions.
注意: ビットはUNIXにおけるスタット(2)システムコールでモードビットが戻ったのと同じです。 ファイルの種類はモードビットとファイルの種類で指定されます。 これは将来のバージョンで修理されています。
The "rdev" field in the attributes structure is an operating
system specific device specifier. It will be removed and
generalized in the next revision of the protocol.
属性構造の"rdev"分野はオペレーティングシステムの特定のデバイス特許説明書の作成書です。 それは、プロトコルの次の改正で取り除かれて、一般化されるでしょう。
2.3.6. sattr
2.3.6. sattr
struct sattr {
unsigned int mode;
unsigned int uid;
unsigned int gid;
unsigned int size;
timeval atime;
timeval mtime;
};
struct sattr、未署名のintモード; 未署名のint uid; 未署名のintヒツジ暈倒病未署名のintサイズ; timeval atime; (timeval mtime)。
The "sattr" structure contains the file attributes which can be
set from the client. The fields are the same as for "fattr"
above. A "size" of zero means the file should be truncated. A
value of -1 indicates a field that should be ignored.
"sattr"構造はクライアントから設定できるファイル属性を含んでいます。 分野は上の"fattr"のように同じです。 ゼロの「サイズ」は、ファイルが先端を切られるべきであることを意味します。 -1の値は無視されるべきである分野を示します。
2.3.7. filename
2.3.7. ファイル名
typedef string filename<MAXNAMLEN>;
typedefストリングファイル名<MAXNAMLEN>。
The type "filename" is used for passing file names or pathname
components.
タイプ「ファイル名」は、ファイル名かパス名コンポーネントを通過するのに使用されます。
2.3.8. path
2.3.8. 経路
typedef string path<MAXPATHLEN>;
typedefストリング経路<MAXPATHLEN>。
The type "path" is a pathname. The server considers it as a
string with no internal structure, but to the client it is the
name of a node in a filesystem tree.
タイプ「経路」はパス名です。 サーバは、内部の構造なしでそれがストリングであるとみなしますが、クライアントにとって、それはファイルシステム木のノードの名前です。
2.3.9. attrstat
2.3.9. attrstat
union attrstat switch (stat status) {
case NFS_OK:
組合attrstatスイッチ(スタット状態)、NFS_OKをケースに入れてください:
Sun Microsystems, Inc. [Page 17] RFC 1094 NFS: Network File System March 1989
サン・マイクロシステムズ・インク[17ページ]RFC1094NFS: 1989年のネットワークファイルシステム行進
fattr attributes;
default:
void;
};
fattr属性。 デフォルト: 空間。 };
The "attrstat" structure is a common procedure result. It
contains a "status" and, if the call succeeded, it also contains
the attributes of the file on which the operation was done.
"attrstat"構造は常法結果です。 それは「状態」を含んでいます、そして、また、呼び出しが成功したなら、操作が行われたファイルの属性を含んでいます。
2.3.10. diropargs
2.3.10. diropargs
struct diropargs {
fhandle dir;
filename name;
};
struct diropargs、fhandle dir(ファイル名名)。
The "diropargs" structure is used in directory operations. The
"fhandle" "dir" is the directory in which to find the file "name".
A directory operation is one in which the directory is affected.
"diropargs"構造はディレクトリ操作に使用されます。 "fhandle""dir"はファイルが「名前」であることがわかるディレクトリです。 ディレクトリ操作はディレクトリが影響を受けるものです。
2.3.11. diropres
2.3.11. diropres
union diropres switch (stat status) {
case NFS_OK:
struct {
fhandle file;
fattr attributes;
} diropok;
default:
void;
};
組合diropresはNFS_OK: ケースstruct fhandleファイル; fattr属性;diropokデフォルト: (空間)を切り換えます(スタット状態)。
The results of a directory operation are returned in a "diropres"
structure. If the call succeeded, a new file handle "file" and
the "attributes" associated with that file are returned along with
the "status".
ディレクトリ操作の結果は"diropres"構造で返されます。 呼び出しが成功したなら、「状態」と共にハンドル「ファイル」という新しいファイルとそのファイルに関連している「属性」を返します。
3. NFS IMPLEMENTATION ISSUES
3. NFS導入問題
The NFS protocol was designed to allow different operating systems to share files. However, since it was designed in a UNIX environment, many operations have semantics similar to the operations of the UNIX file system. This section discusses some of the implementation- specific details and semantic issues.
NFSプロトコルは、異なったオペレーティングシステムがファイルを共有するのを許容するように設計されました。 しかしながら、それがunix環境で設計されたので、多くの操作には、UNIXファイルシステムの操作と同様の意味論があります。 このセクションは実装の特定の詳細と意味問題のいくつかについて論じます。
3.1. Server/Client Relationship
3.1. サーバ/クライアント関係
The NFS protocol is designed to allow servers to be as simple and
そしてNFSプロトコルがサーバが同じくらい簡単であることを許容するように設計されている。
Sun Microsystems, Inc. [Page 18] RFC 1094 NFS: Network File System March 1989
サン・マイクロシステムズ・インク[18ページ]RFC1094NFS: 1989年のネットワークファイルシステム行進
general as possible. Sometimes the simplicity of the server can be a problem, if the client wants to implement complicated filesystem semantics.
可能であるとしての一般。 クライアントが複雑なファイルシステム意味論を実装したいなら、時々、サーバの簡単さは問題であるかもしれません。
For example, some operating systems allow removal of open files. A process can open a file and, while it is open, remove it from the directory. The file can be read and written as long as the process keeps it open, even though the file has no name in the filesystem. It is impossible for a stateless server to implement these semantics. The client can do some tricks such as renaming the file on remove, and only removing it on close. We believe that the server provides enough functionality to implement most file system semantics on the client.
例えば、いくつかのオペレーティングシステムがオープン・ファイルの取り外しを許容します。 プロセスは、ファイルを開いて、それが開いている間、ディレクトリからそれを取り除くことができます。 プロセスがそれを開くように保つ限り、ファイルを読み書きできます、ファイルには、ファイルシステムにおける名前が全くありませんが。 状態がないサーバが、これらが意味論であると実装するのは、不可能です。 クライアントは閉鎖でそれを取り除いて、取り除くだけのファイルを改名などなどのいくつかのトリックができます。 私たちは、サーバがクライアントの上でほとんどのファイルシステム意味論を実装することができるくらいの機能性を提供すると信じています。
Every NFS client can also potentially be a server, and remote and local mounted filesystems can be freely intermixed. This leads to some interesting problems when a client travels down the directory tree of a remote filesystem and reaches the mount point on the server for another remote filesystem. Allowing the server to follow the second remote mount would require loop detection, server lookup, and user revalidation. Instead, we decided not to let clients cross a server's mount point. When a client does a LOOKUP on a directory on which the server has mounted a filesystem, the client sees the underlying directory instead of the mounted directory.
また、すべてのNFSクライアントが潜在的にサーバであるかもしれません、そして、自由にリモートでローカルの取り付けられたファイルシステムを混ぜることができます。 クライアントが別の遠隔ファイルシステムのために遠隔ファイルシステムと範囲のディレクトリツリーの下側にサーバのマウントポイントを旅行するとき、これはいくつかのおもしろい問題を引き起こします。 サーバが2番目のリモートマウントに続くのを許容するのが輪の検出、サーバルックアップ、およびユーザ再合法化を必要とするでしょう。 代わりに、私たちは、クライアントにサーバのマウントポイントを横断させないと決めました。 クライアントがサーバがファイルシステムを取り付けたディレクトリでLOOKUPをすると、クライアントは取り付けられたディレクトリの代わりに基本的なディレクトリを見ます。
For example, if a server has a file system called "/usr" and mounts another file system on "/usr/src", if a client mounts "/usr", it does NOT see the mounted version of "/usr/src". A client could do remote mounts that match the server's mount points to maintain the server's view. In this example, the client would also have to mount "/usr/src" in addition to "/usr", even if they are from the same server.
「例えば、システムが」 /と呼んだファイルがサーバで」 マウントをusrするなら、別のものは"/usr/src"にシステムをファイルします、クライアントが」 /usrを取り付けるなら」、それ。"/usr/src"の取り付けられたバージョンを見ません。 クライアントはサーバの視点を維持するためにサーバのマウントポイントに合っているリモートマウントができました。 「また、この例では、クライアントは」 /usrに加えて"/usr/src"を取り付けなければならないでしょう」、彼らが同じサーバから来ても。
3.2. Pathname Interpretation
3.2. パス名解釈
There are a few complications to the rule that pathnames are always parsed on the client. For example, symbolic links could have different interpretations on different clients. Another common problem for non-UNIX implementations is the special interpretation of the pathname ".." to mean the parent of a given directory. The next revision of the protocol uses an explicit flag to indicate the parent instead.
パス名がクライアントの上でいつも分析されるという規則へのいくつかの複雑さがあります。 例えば、シンボリックリンクは異なったクライアントの上に異なった解釈を持っているかもしれません。 「非UNIX実装のための別の共有する問題はパス名の特別な解釈です。」. . 」 与えられたディレクトリについて親を意味するために。 プロトコルの次の改正は、代わりに親を示すのに明白な旗を使用します。
3.3. Permission Issues
3.3. 許可問題
The NFS protocol, strictly speaking, does not define the permission checking used by servers. However, it is expected that a server will do normal operating system permission checking using AUTH_UNIX style
厳密に言うと、NFSプロトコルはサーバによって使用される許可の照合を定義しません。 しかしながら、サーバがAUTH_UNIXスタイルを使用することでチェックする正常なオペレーティングシステム許可をすると予想されます。
Sun Microsystems, Inc. [Page 19] RFC 1094 NFS: Network File System March 1989
サン・マイクロシステムズ・インク[19ページ]RFC1094NFS: 1989年のネットワークファイルシステム行進
authentication as the basis of its protection mechanism. The server gets the client's effective "uid", effective "gid", and groups on each call and uses them to check permission. There are various problems with this method that can been resolved in interesting ways.
保護メカニズムの基礎としての認証。 サーバは、各呼び出しに関するクライアントの有効な"uid"、有効な「ヒツジ暈倒病」、およびグループを得て、許可をチェックするのにそれらを使用します。 おもしろい方法で決心しているそうすることができるこのメソッドに関する様々な問題があります。
Using "uid" and "gid" implies that the client and server share the same "uid" list. Every server and client pair must have the same mapping from user to "uid" and from group to "gid". Since every client can also be a server, this tends to imply that the whole network shares the same "uid/gid" space. AUTH_DES (and the next revision of the NFS protocol) uses string names instead of numbers, but there are still complex problems to be solved.
"uid"と「ヒツジ暈倒病」を使用するのは、クライアントとサーバが同じ"uid"リストを共有するのを含意します。 すべてのサーバとクライアント組には、ユーザから"uid"までグループから「ヒツジ暈倒病」まで同じマッピングがなければなりません。 また、すべてのクライアントがサーバであるかもしれないので、これは、全体のネットワークが同じ「uid/ヒツジ暈倒病」スペースを共有するのを含意する傾向があります。 AUTH_DES(そして、NFSプロトコルの次の改正)は数の代わりにストリング名を使用しますが、解決されるために、複雑な問題がまだあります。
Another problem arises due to the usually stateful open operation. Most operating systems check permission at open time, and then check that the file is open on each read and write request. With stateless servers, the server has no idea that the file is open and must do permission checking on each read and write call. On a local filesystem, a user can open a file and then change the permissions so that no one is allowed to touch it, but will still be able to write to the file because it is open. On a remote filesystem, by contrast, the write would fail. To get around this problem, the server's permission checking algorithm should allow the owner of a file to access it regardless of the permission setting.
別の問題は通常statefulな開放的手術のため起こります。 次に、ほとんどのオペレーティングシステムが、オープンタイムに許可をチェックして、ファイルが読まれたそれぞれで開いているのをチェックして、要求を書きます。 状態がないサーバで、サーバは、ファイルが開いているという考えを全く持たないで、読まれたそれぞれについて検査して、許可して、呼び出しを書かなければなりません。 ユーザがローカルのファイルシステムでは、ファイルを開いて、次に、許容を変えることができるので、だれもそれに触れることができませんが、それが開いているので、まだファイルに書くことができるでしょう。 書いてください。オンである、対照的に、遠隔ファイルシステム、失敗するでしょう。 この問題を逃れるために、サーバの許可照合アルゴリズムで、ファイルの所有者は許可設定にかかわらずそれにアクセスできるべきです。
A similar problem has to do with paging in from a file over the network. The operating system usually checks for execute permission before opening a file for demand paging, and then reads blocks from the open file. The file may not have read permission, but after it is opened it does not matter. An NFS server can not tell the difference between a normal file read and a demand page-in read. To make this work, the server allows reading of files if the "uid" given in the call has either execute or read permission on the file.
同様の問題はネットワークの上で中でファイルからページングと関係があります。 デマンドページングのためのファイルを開く前に許可を実行して、オープン・ファイルからのブロックがその時読むので、通常、オペレーティングシステムはチェックします。 ファイルは許可を読んでいないかもしれませんが、開かれた後にそれは重要ではありません。 NFSサーバは、中のページが読んだと読まれた正常なファイルと要求の違いに言うことができません。 この仕事をするように、サーバで、呼び出しで与えられた"uid"がどちらかがファイルの上で許可を実行するか、または読むのをさせるなら、ファイルを読みます。
In most operating systems, a particular user (on UNIX, the user ID zero) has access to all files no matter what permission and ownership they have. This "super-user" permission may not be allowed on the server, since anyone who can become super-user on their workstation could gain access to all remote files. The UNIX server by default maps user id 0 to -2 before doing its access checking. This works except for NFS root filesystems, where super-user access cannot be avoided.
ほとんどのオペレーティングシステムで、それらにどんな許可と所有権があっても、特定のユーザ(UNIXの上でユーザIDゼロ)はすべてのファイルに近づく手段を持っています。 この「スーパーユーザ」許可はサーバで許されないかもしれません、それらのワークステーションの上でスーパーユーザになることができるだれでもすべてのリモートファイルへのアクセスを得ることができたので。 アクセスの照合をする前に、Unixサーバーはデフォルトで0〜-2にユーザイドを写像します。 NFS根のファイルシステムを除いて、これは働いています。そこでは、スーパーユーザアクセスを避けることができません。
3.4. RPC Information
3.4. RPC情報
Authentication
The NFS service uses AUTH_UNIX, AUTH_DES, or AUTH_SHORT style
authentication, except in the NULL procedure where AUTH_NONE is
AUTH_NONEがそうであるNULL手順を除いて、NFSが修理する認証はAUTH_UNIX、AUTH_DES、またはAUTH_SHORTスタイル認証を使用します。
Sun Microsystems, Inc. [Page 20] RFC 1094 NFS: Network File System March 1989
サン・マイクロシステムズ・インク[20ページ]RFC1094NFS: 1989年のネットワークファイルシステム行進
also allowed.
また、許容されています。
Transport Protocols
NFS is supported normally on UDP.
通常、輸送プロトコルNFSはUDPでサポートされます。
Port Number
The NFS protocol currently uses the UDP port number 2049. This is
not an officially assigned port, so later versions of the protocol
use the "Portmapping" facility of RPC.
NFSが現在議定書の中で述べるポートNumberはUDPポートNo.2049を使用します。 これが公式に割り当てられたポートでないので、プロトコルの後のバージョンはRPCの"Portmapping"施設を使用します。
3.5. Sizes of XDR Structures
3.5. XDR構造のサイズ
These are the sizes, given in decimal bytes, of various XDR structures used in the protocol:
これらは10進バイトで与えられたプロトコルに使用される様々なXDR構造のサイズです:
/*
* The maximum number of bytes of data in a READ or WRITE
* request.
*/
const MAXDATA = 8192;
READかWRITE*のデータの最大のバイト数が要求する/**。 */const MAXDATA=8192。
/* The maximum number of bytes in a pathname argument. */ const MAXPATHLEN = 1024;
最大が付番するパス名議論におけるバイトの/*。 */const MAXPATHLEN=1024。
/* The maximum number of bytes in a file name argument. */ const MAXNAMLEN = 255;
ファイルの最大のバイト数が議論と命名する/*。 */const MAXNAMLEN=255。
/* The size in bytes of the opaque "cookie" passed by READDIR. */ const COOKIESIZE = 4;
不透明な「クッキー」のバイトで表現されるサイズがREADDIRで通過した/*。 */const COOKIESIZE=4。
/* The size in bytes of the opaque file handle. */ const FHSIZE = 32;
不明瞭なファイルのバイトで表現されるサイズが扱う/*。 */const FHSIZE=32。
3.6. Setting RPC Parameters
3.6. RPCパラメタを設定します。
Various file system parameters and options should be set at mount time. The mount protocol is described in the appendix below. For example, "Soft" mounts as well as "Hard" mounts are usually both provided. Soft mounted file systems return errors when RPC operations fail (after a given number of optional retransmissions), while hard mounted file systems continue to retransmit forever. The maximum transfer sizes are implementation dependent. For efficient operation over a local network, 8192 bytes of data are normally used. This may result in lower-level fragmentation (such as at the IP level). Since some network interfaces may not allow such packets, for operation over slower-speed networks or hosts, or through gateways, transfer sizes of 512 or 1024 bytes often provide better results.
様々なファイルシステム・パラメータとオプションはマウント時に設定されるべきです。 マウントプロトコルは以下の付録で説明されます。 例えば、通常、ともに「困難な」マウントと同様に「柔らかい」マウントを提供します。 RPC操作が失敗すると(任意の「再-トランスミッション」の与えられた数の後に)、柔らかい取り付けられたファイルシステムは誤りを返します、困難な取り付けられたファイルシステムが、いつまでも再送し続けていますが。最大の転送サイズは実装に依存しています。 企業内情報通信網の上の効率的な操作のために、通常、8192バイトのデータは使用されます。 これは低レベル断片化(IPレベルなどの)をもたらすかもしれません。 いくつかのネットワーク・インターフェースが、より遅い速度ネットワークの上の操作かホストか、ゲートウェイを通してそのようなパケットを許容しないかもしれないので、512バイトか1024バイトの転送サイズはしばしばより良い結果を提供します。
Sun Microsystems, Inc. [Page 21] RFC 1094 NFS: Network File System March 1989
サン・マイクロシステムズ・インク[21ページ]RFC1094NFS: 1989年のネットワークファイルシステム行進
Clients and servers may need to keep caches of recent operations to help avoid problems with non-idempotent operations. For example, if the transport protocol drops the response for a Remove File operation, upon retransmission the server may return an error code of NFSERR_NOENT instead of NFS_OK. But if the server keeps around the last operation requested and its result, it could return the proper success code. Of course, the server could be crashed and rebooted between retransmissions, but a small cache (even a single entry) would solve most problems.
クライアントとサーバは、非ベキ等元操作に関する問題を避けるのを助けるために最近の操作のキャッシュを保つ必要があるかもしれません。 例えば、トランスポート・プロトコルがRemove File操作のための応答を下げるなら、「再-トランスミッション」では、サーバはNFS_OKの代わりにNFSERR_NOENTのエラーコードを返すかもしれません。 しかし、サーバが要求された最後の操作とその結果の周りに保たれるなら、それは適切な成功コードを返すかもしれません。 もちろん、「再-トランスミッション」の間でサーバを墜落して、リブートできましたが、小さいキャッシュ(単一のエントリーさえ)はほとんどの問題を解決するでしょう。
Sun Microsystems, Inc. [Page 22] RFC 1094 NFS: Network File System March 1989
サン・マイクロシステムズ・インク[22ページ]RFC1094NFS: 1989年のネットワークファイルシステム行進
Appendix A. MOUNT PROTOCOL DEFINITION
付録A.マウントプロトコル定義
A.1. Introduction
A.1。 序論
The mount protocol is separate from, but related to, the NFS protocol. It provides operating system specific services to get the NFS off the ground -- looking up server path names, validating user identity, and checking access permissions. Clients use the mount protocol to get the first file handle, which allows them entry into a remote filesystem.
マウントプロトコルは分離しますが、NFSプロトコルに関係することです。 サーバパス名を調べて、それはNFSを離陸させるためにオペレーティングシステムの特定のサービスを提供します、ユーザのアイデンティティを有効にして、アクセス許容をチェックして。 クライアントは、最初のファイルハンドルを手に入れるのにマウントプロトコルを使用します。(ハンドルは遠隔ファイルシステムへのエントリーを彼らに許容します)。
The mount protocol is kept separate from the NFS protocol to make it easy to plug in new access checking and validation methods without changing the NFS server protocol.
マウントプロトコルは、NFSサーバプロトコルを変えないで新しいアクセスの照合と合法化メソッドのプラグを差し込むのを簡単にするようにNFSプロトコルから別々に保たれます。
Notice that the protocol definition implies stateful servers because the server maintains a list of client's mount requests. The mount list information is not critical for the correct functioning of either the client or the server. It is intended for advisory use only, for example, to warn possible clients when a server is going down.
サーバがクライアントのマウント要求のリストを維持するのでプロトコル定義がstatefulサーバを含意するのに注意してください。 クライアントかサーバのどちらかの正しい機能には、マウントリスト情報は重要ではありません。例えば、顧問使用だけが、サーバがいつ落ちているかを可能なクライアントに警告するのは、意図しています。
Version one of the mount protocol is used with version two of the NFS protocol. The only information communicated between these two protocols is the "fhandle" structure.
マウントプロトコルのバージョン1はNFSプロトコルのバージョンtwoと共に使用されます。 これらの2つのプロトコルの間で伝えられた唯一の情報が"fhandle"構造です。
A.2. RPC Information
A.2。 RPC情報
Authentication
The mount service uses AUTH_UNIX and AUTH_NONE style
authentication only.
認証マウントサービス用途AUTH_UNIXとAUTH_NONEは認証だけを流行に合わせます。
Transport Protocols
The mount service is supported on both UDP and TCP.
マウントサービスがUDPとTCPの両方でサポートされるプロトコルを輸送してください。
Port Number
Consult the server's portmapper, described in RFC 1057, "RPC:
Remote Procedure Call Protocol Specification", to find the port
number on which the mount service is registered.
サーバのポートマッパーであって、RFC1057で説明されたNumber Consultを移植してください、「RPC:」 「リモートProcedure CallプロトコルSpecification」、ポートナンバーがオンであることがわかるために、マウントが修理するものは登録されています。
A.3. Sizes of XDR Structures
A.3。 XDR構造のサイズ
These are the sizes, given in decimal bytes, of various XDR structures used in the protocol:
これらは10進バイトで与えられたプロトコルに使用される様々なXDR構造のサイズです:
/* The maximum number of bytes in a pathname argument. */
const MNTPATHLEN = 1024;
最大が付番するパス名議論におけるバイトの/*。 */const MNTPATHLEN=1024。
Sun Microsystems, Inc. [Page 23] RFC 1094 NFS: Network File System March 1989
サン・マイクロシステムズ・インク[23ページ]RFC1094NFS: 1989年のネットワークファイルシステム行進
/* The maximum number of bytes in a name argument. */
const MNTNAMLEN = 255;
aの最大のバイト数が議論と命名する/*。 */const MNTNAMLEN=255。
/* The size in bytes of the opaque file handle. */
const FHSIZE = 32;
不明瞭なファイルのバイトで表現されるサイズが扱う/*。 */const FHSIZE=32。
A.4. Basic Data Types
A.4。 基本のデータ型
This section presents the data types used by the mount protocol. In many cases they are similar to the types used in NFS.
このセクションはマウントプロトコルによって使用されるデータ型を提示します。 多くの場合、それらはNFSで使用されるタイプと同様です。
A.4.1. fhandle
A.4.1fhandle
typedef opaque fhandle[FHSIZE];
typedefの不透明なfhandle[FHSIZE]。
The type "fhandle" is the file handle that the server passes to the client. All file operations are done using file handles to refer to a file or directory. The file handle can contain whatever information the server needs to distinguish an individual file.
タイプ"fhandle"はサーバがクライアントに渡すファイルハンドルです。 すべてのファイル操作がファイルかディレクトリを参照するのにファイルハンドルを使用し終わっています。 ファイルハンドルはサーバが個々のファイルを区別するために必要とするどんな情報も含むことができます。
This is the same as the "fhandle" XDR definition in version 2 of the NFS protocol; see section "2.3.3. fhandle" under "Basic Data Types".
これはNFSプロトコルのバージョン2との"fhandle"XDR定義と同じです。 「基礎データタイプ」の下で「2.3.3fhandle」というセクションを見てください。
A.4.2. fhstatus
A.4.2fhstatus
union fhstatus switch (unsigned status) {
case 0:
fhandle directory;
default:
void;
}
組合fhstatusスイッチ(未署名の状態)0をケースに入れてください: fhandleディレクトリ、デフォルトとしてください: 空間
The type "fhstatus" is a union. If a "status" of zero is returned, the call completed successfully, and a file handle for the "directory" follows. A non-zero status indicates some sort of error. In this case, the status is a UNIX error number.
タイプ"fhstatus"は組合です。 ゼロの「状態」を返すなら、首尾よく終了する呼び出しと、「ディレクトリ」尾行のためにファイルハンドルです。 非ゼロ状態はある種の誤りを示します。 この場合、状態はUNIXエラー番号です。
A.4.3. dirpath
A.4.3dirpath
typedef string dirpath<MNTPATHLEN>;
typedefストリングdirpath<MNTPATHLEN>。
The type "dirpath" is a server pathname of a directory.
タイプ"dirpath"はディレクトリのサーバパス名です。
A.4.4. name
A.4.4名前
typedef string name<MNTNAMLEN>;
typedefストリング名前<MNTNAMLEN>。
The type "name" is an arbitrary string used for various names.
タイプ「名前」は様々な名前に使用される任意のストリングです。
Sun Microsystems, Inc. [Page 24] RFC 1094 NFS: Network File System March 1989
サン・マイクロシステムズ・インク[24ページ]RFC1094NFS: 1989年のネットワークファイルシステム行進
A.5. Server Procedures
A.5。 サーバ手順
The following sections define the RPC procedures supplied by a mount server.
以下のセクションはマウントサーバによって供給されたRPC手順を定義します。
/*
* Protocol description for the mount program
*/
program MOUNTPROG {
/*
* Version 1 of the mount protocol used with
* version 2 of the NFS protocol.
*/
version MOUNTVERS {
マウントプログラム*/プログラムMOUNTPROGのための/**プロトコル記述、マウントプロトコルの/**バージョン1は*と共に. NFSプロトコル*/バージョンMOUNTVERSのバージョン2を使用しました。
void
MOUNTPROC_NULL(void) = 0;
MOUNTPROC_NULL(空の)=0を欠如させてください。
fhstatus
MOUNTPROC_MNT(dirpath) = 1;
fhstatus MOUNTPROC_MNT(dirpath)=1。
mountlist
MOUNTPROC_DUMP(void) = 2;
mountlist MOUNTPROC_DUMP(空の)=2。
void
MOUNTPROC_UMNT(dirpath) = 3;
MOUNTPROC_UMNT(dirpath)=3を欠如させてください。
void
MOUNTPROC_UMNTALL(void) = 4;
MOUNTPROC_UMNTALL(空の)=4を欠如させてください。
exportlist
MOUNTPROC_EXPORT(void) = 5;
} = 1;
} = 100005;
exportlist MOUNTPROC_EXPORT(空の)=5。 } = 1; } = 100005;
A.5.1. Do Nothing
A.5.1。 何もしないでください。
void
MNTPROC_NULL(void) = 0;
MNTPROC_NULL(空の)=0を欠如させてください。
This procedure does no work. It is made available in all RPC services to allow server response testing and timing.
この手順は全く仕事をしません。 サーバ応答にテストとタイミングを許容するためにそれをすべてのRPCサービスで利用可能にします。
A.5.2. Add Mount Entry
A.5.2。 山のEntryを加えてください。
fhstatus
MNTPROC_MNT(dirpath) = 1;
fhstatus MNTPROC_MNT(dirpath)=1。
Sun Microsystems, Inc. [Page 25] RFC 1094 NFS: Network File System March 1989
サン・マイクロシステムズ・インク[25ページ]RFC1094NFS: 1989年のネットワークファイルシステム行進
If the reply "status" is 0, then the reply "directory" contains the file handle for the directory "dirname". This file handle may be used in the NFS protocol. This procedure also adds a new entry to the mount list for this client mounting "dirname".
回答「状態」が0であるなら、回答「ディレクトリ」は"dirname"というディレクトリのためのファイルハンドルを含んでいます。 このファイルハンドルはNFSプロトコルに使用されるかもしれません。 また、この手順はこのクライアントの上がっている"dirname"のために新しいエントリーをマウントリストに追加します。
A.5.3. Return Mount Entries
A.5.3。 リターン山のエントリー
struct *mountlist {
name hostname;
dirpath directory;
mountlist nextentry;
};
struct*mountlistはdirpathホスト名;ディレクトリ(mountlist nextentry)を命名します。
mountlist
MNTPROC_DUMP(void) = 2;
mountlist MNTPROC_DUMP(空の)=2。
Returns the list of remote mounted filesystems. The "mountlist" contains one entry for each "hostname" and "directory" pair.
取り付けられたファイルシステム"mountlist"が1つのエントリーを含むリモートのリストにそれぞれの「ホスト名」と「ディレクトリ」組を返します。
A.5.4. Remove Mount Entry
A.5.4。 山のEntryを取り除いてください。
void
MNTPROC_UMNT(dirpath) = 3;
MNTPROC_UMNT(dirpath)=3を欠如させてください。
Removes the mount list entry for the input "dirpath".
入力"dirpath"のためにマウントリストエントリーを取り除きます。
A.5.5. Remove All Mount Entries
A.5.5。 すべての山のEntriesを取り除いてください。
void
MNTPROC_UMNTALL(void) = 4;
MNTPROC_UMNTALL(空の)=4を欠如させてください。
Removes all of the mount list entries for this client.
マウントリストエントリーのすべてをこのクライアントに移します。
A.5.6. Return Export List
A.5.6。 リターン輸出品目録
struct *groups {
name grname;
groups grnext;
};
struct*グループはgrname(グループgrnext)を命名します。
struct *exportlist {
dirpath filesys;
groups groups;
exportlist next;
};
struct*「外-恰幅のい-者」、dirpath filesysグループ; (次のグループ「外-恰幅のい-者」)。
exportlist
MNTPROC_EXPORT(void) = 5;
exportlist MNTPROC_EXPORT(空の)=5。
Sun Microsystems, Inc. [Page 26] RFC 1094 NFS: Network File System March 1989
サン・マイクロシステムズ・インク[26ページ]RFC1094NFS: 1989年のネットワークファイルシステム行進
Returns a variable number of export list entries. Each entry contains a filesystem name and a list of groups that are allowed to import it. The filesystem name is in "filesys", and the group name is in the list "groups".
可変数の輸出品目録エントリーを返します。 各エントリーはそれをインポートすることができるグループのファイルシステム名とリストを含んでいます。 ファイルシステム名が"filesys"にあります、そして、グループ名が「グループ」というリストにあります。
Notes: The exportlist should contain more information about the status of the filesystem, such as a read-only flag.
注意: 「外-恰幅のい-者」は書き込み禁止旗などのファイルシステムの状態に関する詳しい情報を含むはずです。
Author's Address:
作者のアドレス:
Bill Nowicki Sun Microsystems, Inc. Mail Stop 1-40 2550 Garcia Avenue Mountain View, CA 94043
ビル・Nowickiサン・マイクロシステムズ・インクメール停止1-40 2550ガルシア・Avenueマウンテンビュー、カリフォルニア 94043
Phone: (415) 336-7278
以下に電話をしてください。 (415) 336-7278
Email: nowicki@SUN.COM
メール: nowicki@SUN.COM
Sun Microsystems, Inc. [Page 27]
サン・マイクロシステムズ・インク[27ページ]
一覧
スポンサーリンク
