RFC1037 日本語訳
1037 NFILE - a file access protocol. B. Greenberg, S. Keene. December 1987. (Format: TXT=197312 bytes) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group B. Greenberg
Request for Comments: 1037 S. Keene
December 1987
コメントを求めるワーキンググループB.グリーンバーグ要求をネットワークでつないでください: 1037秒間キーン1987年12月
NFILE - A File Access Protocol
NFILE--ファイルアクセス・プロトコル
STATUS OF THIS MEMO
このメモの状態
This document includes a specification of the NFILE file access protocol and its underlying levels of protocol, the Token List Transport Layer and Byte Stream with Mark. The goal of this specification is to promote discussion of the ideas described here, and to encourage designers of future file protocols to take advantage of these ideas. A secondary goal is to make the specification available to sites that might benefit from implementing NFILE. The distribution of this document is unlimited.
このドキュメントはマークがいるNFILEファイルアクセス・プロトコルの仕様と基本的なレベルのプロトコル、Token List Transport Layer、およびByte Streamを含んでいます。 この仕様の目標は、ここで説明された考えの議論を促進して、将来のファイルプロトコルのデザイナーがこれらの考えを利用するよう奨励することです。 セカンダリ目標は仕様をNFILEを実装するのから利益を得るかもしれないサイトに利用可能にすることです。 このドキュメントの分配は無制限です。
TABLE OF CONTENTS
Page
1. INTRODUCTION 3
目次1ページ。 序論3
2. NFILE PROTOCOL LAYERING 4
2. NFILEプロトコルレイヤリング4
3. OVERVIEW OF AN NFILE SESSION 5
3. NFILEセッション5の概要
4. NFILE CONTROL AND DATA CONNECTIONS 6
4. NFILEコントロールとデータコネクションズ6
5. NFILE FILE OPENING MODES 7
5. NFILEファイル・オープニングモード7
6. NFILE CHARACTER SET 9
6. NFILE文字集合9
7. CONVENTIONS USED IN THIS DOCUMENT 10
7. このドキュメント10で使用されるコンベンション
7.1 Mapping Data Types Into Token List Representation 10
7.2 Format of NFILE Commands and Responses 10
7.3 Data Channel Handles and Direct File Identifiers 13
7.4 Syntax of File and Directory Pathname Arguments 13
7.5 Format of NFILE File Property/Value Pairs 14
NFILEコマンドと応答10 7.3のデータのトークンリスト表現10 7.2形式にデータ型を写像する7.1がハンドルと直接編成ファイル識別子を向ける、13、7.4構文、NFILEファイル特性/価値のペア14のファイルとディレクトリパス名議論13 7.5形式
8. NFILE COMMANDS 16
8. NFILEコマンド16
8.1 ABORT Command 16
8.2 CHANGE-PROPERTIES Command 16
8.3 CLOSE Command 17
8.4 COMPLETE Command 19
8.5 CONTINUE Command 20
8.1がコマンド16 8.2の変化特性のコマンド16 8.3の厳密なコマンド17 8.4の完全なコマンドを中止する、19、8.5、コマンド20を続けてください。
Greenberg & Keene [Page 1] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[1ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
8.6 CREATE-DIRECTORY Command 21
8.7 CREATE-LINK Command 21
8.8 DATA-CONNECTION Command 22
8.9 DELETE Command 23
8.10 DIRECT-OUTPUT Command 23
8.11 DIRECTORY Command 24
8.11.1 NFILE DIRECTORY Data Format 26
8.12 DISABLE-CAPABILITIES Command 27
8.13 ENABLE-CAPABILITIES Command 28
8.14 EXPUNGE Command 28
8.15 FILEPOS Command 29
8.15.1 Implementation Hint for FILEPOS Command 30
8.16 FINISH Command 30
8.17 HOME-DIRECTORY Command 31
8.18 LOGIN Command 32
8.19 MULTIPLE-FILE-PLISTS Command 34
8.20 OPEN Command 35
8.20.1 NFILE OPEN Optional Keyword/Value Pairs 39
8.20.2 NFILE OPEN Response Return Values 45
8.21 PROPERTIES Command 47
8.22 READ Command 49
8.23 RENAME Command 50
8.24 RESYNCHRONIZE-DATA-CHANNEL Command 51
8.24.1 Implementation Hints for RESYNCHRONIZE-DATA- 51
CHANNEL Command
8.25 UNDATA-CONNECTION Command 52
リンクを作成しているディレクトリを作成している8.6コマンド21 8.7コマンド21 8.8データ接続命令、22、8.9、28 8.15FILEPOSコマンド29 8.15.1実装がFILEPOSコマンド30 8.16終え命令のためにほのめかす能力を可能にしている能力を無効にしているコマンド23 8.10ダイレクト出力命令23 8.11ディレクトリコマンド24 8.11.1NFILEディレクトリデータの形式26 8.12コマンド27 8.13命令28 8.14梢消コマンドを削除してください、30、8; 17 開いている特性が47 8.22に命令するコマンド49 8.23が読まれたホームディレクトリコマンド31 8.18ログイン命令32 8.19複数のファイルPLISTSコマンド34 8.20開いているコマンド35 8.20.1のNFILEの開いている任意のキーワード/価値のペア39 8.20.2のNFILE応答リターン値45 8.21が.1実装がRESYNCHRONIZEデータ-51チャネル指令8.25UNDATA-接続命令52のためにほのめかすRESYNCHRONIZE-データ・チャンネルコマンド51 8.24にコマンド50 8.24を改名します。
9. NFILE RESYNCHRONIZATION PROCEDURE 53
9. NFILE RESYNCHRONIZATION手順53
9.1 NFILE Control Connection Resynchronization 54
9.2 NFILE Data Connection Resynchronization 55
9.1 NFILEコントロール接続Resynchronization54 9.2NFILEデータ接続Resynchronization55
10. NFILE ERRORS AND NOTIFICATIONS 58
10. NFILE誤りと通知58
10.1 Notifications From the NFILE Server 58
10.2 NFILE Command Response Errors 59
10.3 NFILE Asynchronous Errors 60
10.4 NFILE Three-letter Error Codes 61
NFILEサーバ58 10.2NFILEからの10.1の通知が応答誤り59 10.3のNFILEの非同期な誤り60 10.4のNFILEの3文字のエラーコード61を命令します。
11. TOKEN LIST TRANSPORT LAYER 65
11. トークンリストトランスポート層65
11.1 Introduction to the Token List Transport Layer 65
11.2 Token List Stream 66
11.2.1 Types of Tokens and Token Lists 66
11.2.2 Token List Stream Example 68
11.2.3 Mapping of Lisp Objects to Token List Stream 70
Representation
11.2.4 Aborting and the Token List Stream 71
トークンリストトランスポート層65 11.2トークンリストストリーム66 11.2.1のタイプのトークンとトークンリストストリーム70表現への舌足らずオブジェクトに関するトークンリスト66 11.2.2トークンリストストリームの例68 11.2の.3マッピングへの11.1序論、11.2、.4が中止になる、トークンリストストリーム71
Greenberg & Keene [Page 2] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[2ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
11.3 Token List Data Stream 72
11.3 トークンリストデータ・ストリーム72
12. BYTE STREAM WITH MARK 73
12. マーク73とのバイト・ストリーム
12.1 Discussion of Byte Stream with Mark 73
12.2 Byte Stream with Mark Abortable States 75
12.1 マークAbortable州75とのマーク73 12.2バイト・ストリームとのバイト・ストリームの議論
13. POSSIBLE FUTURE EXTENSIONS 77
13. 可能な今後の拡大77
APPENDIX A. NORMAL TRANSLATION MODE 79
付録のA.の正常な翻訳モード79
APPENDIX B. RAW TRANSLATION MODE 83
付録のB.の生の翻訳モード83
APPENDIX C. SUPER-IMAGE TRANSLATION MODE 84
付録C.超イメージ翻訳モード84
NOTES 86
注意86
LIST OF TABLES
テーブルのリスト
TABLE 1. TRANSLATIONS FROM NFILE CHARACTERS TO UNIX CHARACTERS 80
TABLE 2. TRANSLATIONS FROM UNIX CHARACTERS TO NFILE CHARACTERS 80
TABLE 3. TRANSLATIONS FROM NFILE TO PDP-10 CHARACTERS 81
TABLE 4. TRANSLATIONS FROM PDP-10 CHARACTERS TO NFILE 82
CHARACTERS
TABLE 5. SUPER-IMAGE TRANSLATION FROM NFILE TO ASCII 84
TABLE 6. SUPER-IMAGE TRANSLATION FROM ASCII TO NFILE 85
1を見送ってください。 NFILEキャラクタからUNIXキャラクタ80までの翻訳は2を見送ります。 UNIXキャラクタからNFILEキャラクタ80までの翻訳は3を見送ります。 NFILEからPDP-10キャラクタ81までの翻訳は4を見送ります。 PDP-10キャラクタからNFILE82キャラクタまでの翻訳は5を見送ります。 NFILEからASCII84テーブル6までの超イメージ翻訳。 ASCIIからNFILE85までの超イメージ翻訳
1. INTRODUCTION
1. 序論
NFILE stands for "New File Protocol". NFILE was originally designed as a replacement for an older protocol named QFILE, with the goal of solving robustness problems of QFILE, hence the name "New File Protocol".
NFILEは「新しいファイルプロトコル」を表します。 より古いプロトコルとの交換がしたがって、QFILEの丈夫さ問題を解決するという目標、名前があるQFILEを「新しいファイルプロトコル」と命名したとき、NFILEは元々、設計されました。
NFILE was designed and implemented at Symbolics by Bernard S. Greenberg. Mike McMahon made important contributions, especially in the design and implementation of the Byte Stream with Mark and Token List Transport layers. NFILE has been used successfully for file access between Symbolics computers since 1985. NFILE servers have been written for UNIX hosts as well. NFILE is intended for use by any type of file system, not just the native Symbolics file system.
NFILEはSymbolicsでバーナード・S.グリーンバーグによって設計されて、実装されました。 マイクマクマホンは特にマークとToken List TransportとのByte Streamの設計と実装における重要な貢献を層にしました。 1985年以来NFILEはSymbolicsコンピュータの間のファイルアクセスに首尾よく使用されています。 NFILEサーバはまた、UNIXホストのために書かれています。 NFILEは使用のために固有のSymbolicsファイルシステムだけではなく、どんなファイル形式システムでも意図します。
NFILE is a file access protocol that supports a large set of operations on files and directories on remote systems, including:
NFILEはリモートシステムの上のファイルとディレクトリの上で大きい操作をサポートするファイルアクセス・プロトコルです、である:
- Reading and writing entire files
- Reading and writing selected portions of files
- Deleting and renaming files
- ファイル全体を読み書きします--ファイルを削除して、改名して、読み書きはファイルの一部を選択しました。
Greenberg & Keene [Page 3] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[3ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
- Creating links
- Listing, creating, and expunging directories
- Listing and changing the properties of files
- Enabling and disabling access capabilities on a remote
host
- リンクを作成します--リモートホストの上でアクセスが能力であると可能にして、無効にしながら、ファイルの資産を記載して、変えるというディレクトリを記載して、作成して、梢消すること。
NFILE supports file transfer of binary or character files.
NFILEはバイナリーかキャラクタファイルのファイル転送をサポートします。
The NFILE server provides information about any errors that occur in the course of a command. In addition, NFILE has a robust scheme for handling aborts on the user side.
NFILEサーバはコマンドの間に発生するどんな誤りの情報も提供します。 さらに、NFILEはユーザ側に取り扱いアボートの強健な体系を持っています。
This specification defines NFILE user version 2 and server version 2. We do not envision NFILE as an unchanging protocol, but rather as a protocol that could continue to develop if additional requirements are identified though the process of this Request for Comments. The design of NFILE makes room for various useful extensions. Some of the extensions that we are considering are described later on in this document: See the section "Possible Future Extensions", section 13.
この仕様はNFILEユーザバージョン2とサーババージョン2を定義します。 私たちは、変らないプロトコルとしてNFILEを思い描くのではなく、むしろCommentsのためのこのRequestのプロセスですが、追加要件が特定されるなら展開し続けるかもしれないプロトコルとして思い描きます。 NFILEのデザインは様々な役に立つ拡大に場所を開けます。 私たちが考えている拡大のいくつかが後で本書では説明されます: 「可能な今後の拡大」というセクション、セクション13を見てください。
2. NFILE PROTOCOL LAYERING
2. NFILEプロトコルレイヤリング
NFILE is a layered file protocol. The layers are:
NFILEは層にされたファイルプロトコルです。 層は以下の通りです。
+-----------------------------------------------+
|client program or user interface |
+-----------------------------------------------+
|NFILE |
+-----------------------------------------------+
|Token List Transport Layer |
+-----------------------------------------------+
|Byte Stream with Mark |
+-----------------------------------------------+
|reliable host-host byte transmission protocol |
+-----------------------------------------------+
+-----------------------------------------------+ |クライアントプログラムかユーザーインタフェース| +-----------------------------------------------+ |NFILE| +-----------------------------------------------+ |トークンリストトランスポート層| +-----------------------------------------------+ |マークとのバイト・ストリーム| +-----------------------------------------------+ |信頼できるホスト兼ホストバイトトランスミッションプロトコル| +-----------------------------------------------+
Byte Stream with Mark is a simple protocol that guarantees that an out-of-band signal can be transmitted in the case of program interruption. Byte Stream with Mark is to be layered upon extant byte stream protocols. An important goal of the NFILE design was that NFILE could be built on any byte stream. It is currently implemented on TCP and Chaosnet. See the section "Byte Stream with Mark", section 12.
マークがいるバイトStreamはプログラム割込みの場合でバンドで出ている信号を送信できるのを保証する簡単なプロトコルです。 マークがいるバイトStreamは実在のバイト・ストリームプロトコルで層にされることになっています。 NFILEデザインの重要な目標はどんなバイト・ストリームのときにもNFILEを造ることができたということでした。 それは現在、TCPとChaosnetで実装されます。 「マークとのバイト・ストリーム」というセクション、セクション12を見てください。
The Token List Transport Layer is a protocol that facilitates the transmission of simple structured data, such as lists. See the section "Token List Transport Layer", section 11.
Token List Transport Layerはリストなどの簡単な構造化されたデータの伝達を容易にするプロトコルです。 「トークンリストトランスポート層」というセクション、セクション11を見てください。
Greenberg & Keene [Page 4] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[4ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
The NFILE commands and command responses are transmitted in "token lists". See the section "NFILE Commands", section 8.
NFILEコマンドとコマンド応答は「トークンリスト」で伝えられます。 「NFILEコマンド」というセクション、セクション8を見てください。
This specification does not include a client program or user interface to the protocol. In the Symbolics implementation, the normal file operations transparently invoke NFILE, when the remote host is known to support NFILE. Another possible interface to NFILE would be through a dedicated client program that would issue NFILE commands in response to explicit requests by the user.
この仕様はクライアントプログラムかユーザーインタフェースをプロトコルに含んでいません。 Symbolics実装では、リモートホストがNFILEをサポートするのが知られていると、通常のファイル操作は透過的にNFILEを呼び出します。 NFILEへの別の可能なインタフェースはユーザによる明白な要求に対応してNFILEにコマンドを発行する専用クライアントプログラムであるでしょう。
3. OVERVIEW OF AN NFILE SESSION
3. NFILEセッションの概要
An NFILE session is a dialogue between two hosts. The host that initiates the NFILE session is known as the "user side", and the other host is the "server side". The user side sends all NFILE commands. The server receives each command, processes it, and responds to it, indicating the success or failure of the command.
NFILEセッションは2人のホストの間の対話です。 NFILEセッションを開始するホストは「ユーザ側」として知られています、そして、もう片方のホストは「サーバ側」です。 ユーザ側はすべてのNFILEコマンドを送ります。 コマンドの成否を示して、サーバは、各コマンドを受け取って、それを処理して、それに反応します。
The user side keeps track of commands sent and command responses received by using "transaction identifiers" to identify each command. The user side generates a transaction identifier (which must be unique per this dialogue) for each command, and sends the transaction identifier to the server along with the command. Each NFILE server response includes the transaction identifier of the command with which the response is associated. The server is not required to respond to commands in the same order that the user gave them.
ユーザ側は、コマンドの道を送り続けます、そして、コマンド応答は、各コマンドを特定するのに「トランザクション識別子」を使用することによって、受信されました。 ユーザ側は、各コマンドのために、トランザクション識別子(この対話単位でユニークであるに違いない)を生成して、トランザクション識別子をコマンドに伴うサーバに送ります。 それぞれのNFILEサーバ応答は応答が関連しているコマンドに関するトランザクション識別子を含んでいます。 サーバは、同次でユーザがそれらを与えたとコマンドに応答するのに必要ではありません。
The user side sends NFILE commands over a bidirectional network connection called the "control connection". The server sends its command responses on the same control connection. The control connection governing the NFILE session is established at the beginning of the session. If the control connection is ever broken, the NFILE session is ended.
ユーザ側は「コントロール接続」と呼ばれる双方向のネットワーク接続の上でコマンドをNFILEに送ります。 サーバは同じコントロール接続にコマンド応答を送ります。 NFILEセッションを治めるコントロール接続はセッションの始めに確立されます。 コントロール接続が失意であるなら、NFILEセッションは終わっています。
Whereas NFILE commands and responses are transmitted on the control connection, file data is transferred over "data channels". An "input data channel" transfers data from server to user. An "output data channel" transfers data from user to server. Each input data channel is associated with an output data channel; together these two channels comprise a "data connection".
コントロール接続のときにNFILEコマンドと応答を伝えますが、「データ・チャンネル」の上にファイルデータを移します。 「入力データ・チャンネル」はサーバからユーザまでデータを移します。 「出力データ・チャンネル」はユーザからサーバまでデータを移します。それぞれの入力データ・チャンネルは出力データ・チャンネルに関連しています。 これらの2個のチャンネルが「データ接続」を一緒に、包括します。
Often more than one NFILE activity is occurring at any given time. For example, several files can be open and transferring data simultaneously; one or more commands can be in process at the same time; and the server can be simultaneously transmitting directory lists and processing further commands. This happens in an implementation in which the user side has multiple processes, and several processes share a single NFILE server.
しばしば、1つ以上のNFILE活動がその時々で起こります。 例えば、いくつかのファイルが、開く場合があって、同時に、データを移します。 同時に、1つ以上のコマンドがプロセスにあることができます。 そして、サーバは、同時に、ディレクトリリストを伝えて、さらなるコマンドを処理できます。 これはユーザ側が複数のプロセスを持っている実装で起こります、そして、いくつかのプロセスがただ一つのNFILEサーバを共有します。
Greenberg & Keene [Page 5] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[5ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
4. NFILE CONTROL AND DATA CONNECTIONS
4. NFILEコントロールとデータ接続
The user and server communicate through a single control connection and a set of data connections. Data connections are established and disestablished by NFILE commands. The user side sends NFILE commands to the server over the control connection. The server responds to every user command over this control connection. The actual file data is transmitted over the data connections.
ユーザとサーバは単一管理接続とデータ接続のセットを通って交信します。 データ接続は、NFILEコマンドで設立されて、廃止されます。 ユーザ側はコントロール接続の上でサーバへのコマンドをNFILEに送ります。 サーバはこのコントロール接続の上のあらゆるユーザコマンドに反応します。 実際のファイルデータはデータ接続の上に伝えられます。
User aborts can disrupt the normal flow of data on the control connection and data connections. An important aspect of any file protocol is the way it handles user aborts. NFILE uses a resynchronization procedure to bring the affected control connection or data channel from an unknown, unsafe state into a known state. After resynchronization, the control connection or data channel can be reused. See the section "NFILE Resynchronization Procedure", section 9.
ユーザアボートはコントロール接続とデータ接続でのデータの正常な流れを混乱させることができます。 どんなファイルプロトコルの重要な一面もユーザアボートを扱う方法です。 NFILEは、未知の、そして、危険な状態から知られている状態に影響を受けるコントロール接続かデータ・チャンネルを連れて来るのに再同期手順を用います。 再同期の後に、コントロール接続かデータ・チャンネルを再利用できます。 「NFILE Resynchronization手順」というセクション、セクション9を見てください。
THE CONTROL CONNECTION
コントロール接続
An NFILE session is begun when the NFILE user program connects to a remote host and establishes a network connection. This initial connection is the control conection of the dialogue. If TCP is used as the underlying protocol, contact NFILE's well-known port, 59. If Chaos is used, use the contact name "NFILE".
NFILEユーザ・プログラムがリモートホストに接して、ネットワーク接続を確立すると、NFILEセッションは始められます。 この初期の接続は対話のコントロールconectionです。 TCPが基本的なプロトコル、接触NFILEのウェルノウンポートとして使用されるなら、59です。 Chaosが使用されているなら、"NFILE"という連絡名を使用してください。
The control connection is the vehicle used by the user to send its commands, and the server to send its command responses. These types of communication occur over the NFILE control connection:
コントロール接続は、コマンドを送るのにユーザによって使用された乗り物と、コマンド応答を送るサーバです。 コミュニケーションのこれらのタイプはNFILEコントロール接続の上に起こります:
- The user side sends NFILE commands.
- The server sends command responses.
- The server sends "notifications" and "asynchronous errors".
See the section "NFILE Errors and Notifications", section 10.
- During resynchronization (a special circumstance) either the
user or server sends a mark.
- ユーザ側はコマンドをNFILEに送ります。 - サーバはコマンド応答を送ります。 - サーバは「通知」と「非同期な誤り」を送ります。 「NFILE誤りと通知」というセクション、セクション10を見てください。 - 再同期(特別な状況)の間、ユーザかサーバがマークを送ります。
All commands, command responses, and other data flowing over the NFILE control connection are transmitted in the format of "top-level token lists". The control connection expects never to receive "loose tokens"; that is, tokens not contained in token lists.
NFILEコントロール接続の上を流れるすべてのコマンド、コマンド応答、および他のデータは「トップレベルトークンリスト」の形式で送られます。 コントロール接続は、「ゆるいトークン」を決して受けないと予想します。 すなわち、トークンはトークンにリストを含みませんでした。
Greenberg & Keene [Page 6] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[6ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
DATA CONNECTIONS
データ接続
Data connections are established and discarded at user request, by means of two NFILE commands: DATA-CONNECTION and UNDATA-CONNECTION. Each data connection is associated with a specific control connection, which is the same control connection that caused the data connection to be established.
データ接続は、ユーザ要求によって2つのNFILEコマンドによって確立されて、捨てられます: データ接続とUNDATA-接続。 それぞれのデータ接続は特定のコントロール接続に関連しています(データ接続を確立させた同じコントロール接続です)。
Each data connection is composed of two "data channels". Each data channel is capable of sending data in one direction. The term "input channel" refers to the data channel that transmits data from the server to the user side; "output channel" refers to the data channel that transmits data from the user to the server side. Throughout the NFILE documentation, the terms "input channel" and "output channel" are seen from the perspective of the user side. A single data channel can be used for one data transfer after another.
それぞれのデータ接続は2「データ・チャンネル」で構成されます。 それぞれのデータ・チャンネルはデータを一方向に送ることができます。 「入力チャンネル」という用語はサーバからユーザ側までデータを送るデータ・チャンネルに言及します。 「出力チャネル」はユーザからサーバ側までデータを送るデータ・チャンネルを示します。 NFILEドキュメンテーション中では、用語「入力チャンネル」と「出力チャネル」にユーザ側の見解から遭遇します。 データ転送に単独のデータ・チャンネルを相次いで使用できます。
The format of the data transferred on the data channels is defined as a "token list data stream". See the section "Token List Data Stream", section 11.3. When the end of data is reached, the keyword token EOF is sent. Occasionally, token lists are transmitted over the data channels, such as asynchronous error descriptions.
データ・チャンネルで移されたデータの書式は「トークンリストデータ・ストリーム」と定義されます。 「トークンリストデータ・ストリーム」というセクション、セクション11.3を見てください。 データの端に達しているとき、キーワードトークンEOFを送ります。 時折、トークンリストは非同期なエラー記述などのデータ・チャンネルの上に伝えられます。
5. NFILE FILE OPENING MODES
5. NFILEファイル・オープニングモード
The NFILE OPEN command opens a file for reading, writing, or "direct access" at the server host. That means, in general, asking the host file system to access the file and obtaining a file number, pointer, or other quantity for subsequent rapid access to the file; this is called an "opening". The term "opening" translates to a file stream in Symbolics terminology, a JFN in TOPS-20 terminology, and a file descriptor in UNIX terminology. An opening usually keeps track of how many bytes have been read or written, and other bookkeeping information.
NFILE OPENコマンドはサーバー・ホストで読書、書くこと、または「直接アクセス」のためのファイルを開きます。 それは、一般に、ファイルにアクセスするようにホストファイルシステムに頼んで、ファイル番号、指針、または他の量をファイルへのその後の急速なアクセスに得ることを意味します。 これは「始まり」と呼ばれます。 「開き」という用語はSymbolics用語のファイルストリーム、TOPS-20用語のJFN、およびUNIX用語のファイルディスクリプタに翻訳されます。 通常、始まりはバイトがいくつに読み込まれるか、または書かれているか、そして、他の簿記情報の動向をおさえます。
NFILE supports two ways of transferring file data, "data stream mode" and "direct access mode". A single mode is associated with each opening. Note that an NFILE dialogue can have more than one opening, and thus use both modes.
NFILEはファイルデータを移す2つの方法、「データ・ストリームモード」、および「直接アクセスモード」をサポートします。 単モードは各始まりに関連しています。 NFILE対話が1つ以上の始まりを持つことができることに注意してください、そして、その結果、両方のモードを使用してください。
DATA STREAM MODE:
データはモードを流します:
Data stream mode of file transfer is the default mode of NFILE's OPEN command. Data stream mode is appropriate when the entire file is transferred, either from user to server, or from server to user. Data stream mode is used more often than direct access mode.
ファイル転送のデータ・ストリームモードはNFILEのオープン命令のデフォルトモードです。 ユーザからサーバまでサーバからユーザまでファイル全体を移すとき、データ・ストリームモードは適切です。 データ・ストリームモードはアクセス・モードを指示するよりしばしば使用されます。
Greenberg & Keene [Page 7] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[7ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
The OPEN command includes a "handle" argument, which identifies the data channel to be used to transfer the data. The handle is used in subsequent commands to reference this particular opening. When a data stream opening is requested with the OPEN command, the file is opened and the data begins to flow immediately.
オープン命令は「ハンドル」議論を含んでいます。(それは、データを移すのに使用されるためにデータ・チャンネルを特定します)。 使用されるハンドルはその後でこの特定の始まりを参照に命令します。 データ・ストリーム始まりがオープン命令で要求されているとき、ファイルは開かれます、そして、データはすぐに、流れ始めます。
The sending side transmits the entire contents of the specified file over the specified data channel as rapidly as the network permits. When the sending side reaches the end of the file, it transmits a special control token to signal end of file. The receiving side expects an uninterrupted stream of bytes to appear immediately on its side of the data channel.
送付側はネットワークが可能にするのと同じくらい急速に指定されたファイルの全体のコンテンツを指定されたデータ・チャンネルの上に伝えます。 送付側がファイルの端に達すると、それは、ファイルの終りに合図するために特別なコントロールトークンを伝えます。 受信側は、バイトのとぎれないストリームがすぐデータ・チャンネルの側面に載っていると予想します。
The user gives the CLOSE command to terminate a data stream transfer. CLOSE results in closing the file.
ユーザはデータ・ストリーム転送を終えるCLOSEコマンドを与えます。 最後になりましたが、CLOSEは結果になります。ファイル。
DIRECT ACCESS MODE:
アクセス・モードを指示してください:
Direct access mode enables reading or writing data from a given starting point in a file through a specified number of bytes. In direct access mode, data is requested and sent in individual transactions. To request a direct access mode opening, the OPEN command is used with a DIRECT-FILE-ID argument. (In data stream mode, no DIRECT-FILE-ID is supplied.) The direct file identifier is used in subsequent commands to reference the direct access opening.
ファイルにおける与えられた出発点から指定された数のバイトまでデータを読むか、または書くモードが可能にするアクセスを指示してください。 直接アクセスモードで、個々のトランザクションでデータを要求して、送ります。 直接アクセスモード始まりを要求するために、オープン命令はDIRECT-FILE-ID議論と共に使用されます。 (データ・ストリームモードで、DIRECT-FILE-IDを全く供給しません。) 使用される直接編成ファイル識別子はその後で直接アクセス始まりを参照に命令します。
When a file is opened in direct access mode, the flow of data does not start immediately. Rather, the user gives either a READ command (to request data to flow from server to user) or a DIRECT-OUTPUT command (to request data to flow from user to server). When reading, the READ command allows the user to specify the starting point and the number of bytes of data to transfer. When writing, the FILEPOS command can be used to specify the starting point, before the DIRECT-OUTPUT command is given. The user can give many READ and DIRECT-OUTPUT commands, one after another.
ファイルがすぐに直接アクセスモードで開かれるとき、データの流れは始まりません。 むしろ、ユーザはREADコマンド(サーバからユーザまで流れるようデータに要求する)かDIRECT-OUTPUTコマンド(ユーザからサーバまで流れるようデータに要求する)のどちらかを与えます。 読むとき、READコマンドで、ユーザは、移すためにデータの出発点とバイト数を指定できます。 書くとき、DIRECT-OUTPUTコマンドを与える前に出発点を指定するのにFILEPOSコマンドを使用できます。 ユーザは多くのREADとDIRECT-OUTPUTコマンドを相次いで与えることができます。
The user side terminates the direct access transfer by using the CLOSE command. The ABORT command can be given to terminate without transmitting all of the specified bytes.
ユーザ側は、CLOSEコマンドを使用することによって、直接アクセス転送を終えます。 指定されたバイトのすべてを伝えないで終わるためにABORTコマンドを与えることができます。
Greenberg & Keene [Page 8] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[8ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
6. NFILE CHARACTER SET
6. NFILE文字集合
The NFILE character set <1> is an extension of standard ASCII. NFILE command and response names use only the standard ASCII characters. However, the protocol supports the transfer of the non-ASCII characters in the NFILE character set; these characters might be stored in files, or might be used in pathnames.
NFILE文字集合<1>は標準のASCIIの拡大です。 NFILEコマンドと応答名は標準のASCII文字だけを使用します。 しかしながら、プロトコルはNFILE文字集合における、非ASCII文字の転送をサポートします。 これらのキャラクタは、ファイルに保存されるか、またはパス名に使用されるかもしれません。
Servers on machines that do not natively use the NFILE character set must perform character set translations for character openings, depending on the requested translation mode. No translation is required for binary openings. There are three translation modes for character openings: NORMAL, RAW, and SUPER-IMAGE. Each mode specifies a way to translate between the server's native set and the NFILE character set.
ネイティブにNFILE文字集合を使用しないマシンの上のサーバはキャラクタ始まりのための文字集合翻訳を実行しなければなりません、要求された翻訳モードによって。 翻訳は全く2進の始まりに必要ではありません。 キャラクタ始まりへの3つの翻訳モードがあります: 正常、そして、生と、超像を描きます。 各モードはサーバの自然なセットとNFILE文字集合の間で翻訳する方法を指定します。
NORMAL mode is the default of the OPEN command. The translation for NORMAL mode ensures that a file containing characters in the NFILE character set can be written to a remote host and read back intact. OPEN has optional keyword arguments to specify RAW or SUPER-IMAGE. RAW mode means to perform no translation whatsoever. SUPER-IMAGE mode is intended for use by PDP-10 family machines only. It is included largely as an illustration of a system-dependent extension.
NORMALモードはオープン命令のデフォルトです。 NORMALモードのための翻訳は、NFILE文字集合にキャラクタを含むファイルが完全な状態でリモートホストに書かれていて、読み込み返されることができるのを確実にします。 オープンには、RAWかSUPER-IMAGEを指定する任意のキーワード引数があります。 RAWモードは、翻訳を全く実行しないことを意味します。SUPER-IMAGEモードは使用のためにPDP-10ファミリーマシンだけで意図します。 それは主にシステム依存する拡大のイラストとして含まれています。
The details of each translation mode are given in Appendices:
それぞれの翻訳モードの詳細はAppendicesで明らかにされます:
See the section "NORMAL Translation Mode", Appendix A. See the
section "RAW Translation Mode", Appendix B. See the section
"SUPER-IMAGE Translation Mode", Appendix C.
「正常な翻訳モード」というセクション、「生の翻訳モード」というセクション、Appendix A.See Appendix B.Seeセクション「超イメージ翻訳モード」(Appendix C)を見てください。
The use of the NFILE character set brings up a difficulty involved with determining an exact position within a character file. Some NFILE characters expand to more than one native character on some servers. Thus, for character files, when we speak of a given position in a file or the length of a file, we must specify whether we are speaking in "NFILE units" or "server units", because the counting of characters is different. This causes major problems in file position reckoning for character files. Specifically, it is futile for a user side to carefully monitor file position during output by counting characters, when character translation is in effect. The server's operating system interface for "position to point x in a file" necessarily operates in server units, but the user side has counted in NFILE units. The user side cannot try to second-guess the translation-counting process without losing host- independence. See the section "FILEPOS NFILE Command".
NFILE文字集合の使用はキャラクタファイルの中で正確な位置を決定するのにかかわる困難を持って来ます。 NFILEキャラクタの中にはいくつかのサーバの1つ以上のネイティブのキャラクタに広がる人もいます。 ファイルの与えられた見解かファイルの長さについて話すとき、したがって、キャラクタファイルとして、私たちは、「NFILEユニット」か「サーバユニット」で話しているかどうか指定しなければなりません、キャラクタの勘定が異なっているので。 これはキャラクタファイルのためのファイル位置の計算における大した問題を引き起こします。 明確に、ユーザ側が出力の間、キャラクタを数えることによって慎重にファイルの位置をモニターするのは、空しいです、文字変換が有効であるときに。 「ファイルのxを指す立場」へのサーバのオペレーティングシステムインタフェースは必ずサーバユニットで作動しますが、ユーザ側はNFILEユニットで数えました。 ユーザ側は損をしているホスト独立なしで翻訳計数過程を結果論で批判しようとすることができません。 「FILEPOS NFILEコマンド」というセクションを見てください。
Greenberg & Keene [Page 9] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[9ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
7. CONVENTIONS USED IN THIS DOCUMENT
7. 本書では使用されるコンベンション
7.1 Mapping Data Types Into Token List Representation
7.1 トークンリスト表現にデータ型を写像すること。
Throughout this NFILE specification, the data types of arguments, return values, asynchronous error descriptions, and notifications are described as being strings, integers, dates, time intervals, and so on. However, each conceptual data type must be mapped into the appropriate token list representation for transmission. The mapping of conceptual data types to token list representation is shown here:
このNFILE仕様中では、議論、リターン値、非同期なエラー記述、および通知に関するデータ型はストリング、整数、日付、時間間隔などであるとして記述されています。 しかしながら、トランスミッションの適切なトークンリスト表現にそれぞれの概念的なデータ型を写像しなければなりません。 トークンリスト表現への概念的なデータ型に関するマッピングはここに示されます:
Conceptual Type Token List Representation
概念的なタイプトークンリスト表現
----------------------------------------------------------------
----------------------------------------------------------------
Keyword A keyword token
キーワードAキーワードトークン
Keyword list A token list of keyword tokens
キーワードトークンのキーワードリストAトークンリスト
Integer A numeric data token
整数A数値データトークン
String A data token containing the characters of the
string in the NFILE character set.
NFILE文字集合における、ストリングのキャラクタを含むAデータトークンを結んでください。
Boolean Truth The token known as BOOLEAN-TRUTH.
ブールTruth、ブールTRUTHとして知られているトークン。
Boolean False The empty token list.
空のトークンが記載するブールFalse。
Date A numeric data token. The date is expressed in
Universal Time format, which measures a time as
the number of seconds since January 1, 1900, at
midnight GMT.
数値データトークンとAの日付を入れてください。 日付は世界標準時の形式で言い表されます。(それは、グリニッジ標準時に1900年1月1日、真夜中に以来、秒数として時間を測定します)。
Date-or-never Can be either a date or the empty token list,
representing "never". "Never" is used for
values such as the time a directory was last
expunged, if it has never been expunged.
日付か空のトークンリストのどちらか、“never"を表すことである決してデートされていないCan。 それが一度も梢消されたことがないなら、ディレクトリが最後に梢消された時などの値に」決して使用されません。
Time interval A numeric data token. The time interval is
expressed in seconds. A time interval
indicating "never" is represented by the empty
token list.
時間間隔A数値データトークン。 時間間隔は秒に言い表されます。 “never"を示す時間間隔は空のトークンリストによって表されます。
7.2 Format of NFILE Commands and Responses
7.2 NFILEコマンドと応答の形式
Each command description begins by giving the command format and response format. Here is the beginning of the DATA-CONNECTION command description:
それぞれのコマンド記述は、コマンド形式と応答書式を与えることによって、始まります。 ここに、DATA-CONNECTIONコマンド記述の始まりがあります:
Greenberg & Keene [Page 10] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[10ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
Command: (DATA-CONNECTION tid new-input-handle new-output-handle)
コマンド: (DATA-CONNECTION tidの新しい入力ハンドルの新しい出力ハンドル)
Response: (DATA-CONNECTION tid connection-identifier)
応答: (DATA-CONNECTION tid接続識別子)
The command descriptions follow these conventions:
コマンド記述はこれらのコンベンションを次に続かせます:
1. NFILE commands and responses are transmitted as top-level token
lists.
1. NFILEコマンドと応答はトップレベルトークンリストとして伝えられます。
Top-level token lists are enclosed in parentheses in these
command descriptions. These parentheses are not sent literally
across the control or data connections, but are a shorthand
representation of special control tokens that delimit top-level
token lists. Specifically, TOP-LEVEL-LIST-BEGIN starts a top-
level token list; TOP-LEVEL-LIST-END ends a top-level token list.
トップレベルトークンリストはこれらのコマンド記述における括弧に同封されます。 これらの括弧は、文字通りコントロールかデータ接続の向こう側に送られませんが、トップレベルトークンリストを区切る特別なコントロールトークンの速記表現です。 明確に、TOP-LEVEL-LIST-BEGINは先端の平らなトークンリストを始めます。 TOP-LEVEL-LIST-ENDはトップレベルトークンリストを終わらせます。
2. NFILE command names are keywords.
2. NFILEコマンド名はキーワードです。
The command name is required in every command and command
response. All NFILE command names are keywords. Keywords appear
in the NFILE documentation as their names in uppercase. For
example, DATA-CONNECTION and DELETE are two command names.
コマンド名があらゆるコマンドとコマンド応答で必要です。 すべてのNFILEコマンド名がキーワードです。 キーワードは大文字のそれらの名前としてNFILEドキュメンテーションに載っています。 例えば、DATA-CONNECTIONとDELETEは2つのコマンド名です。
3. A unique transaction identifier (tid) identifies each command.
3. ユニークなトランザクション識別子(tid)は各コマンドを特定します。
The transaction identifier is a string made up by the user side
to identify this particular transaction, which is composed of the
command and the response associated with this command. The
transaction identifier is abbreviated in the command descriptions
as tid. Transaction identifiers are limited to fifteen
characters in length. The transaction identifier is required in
every command and command response.
トランザクション識別子はユーザ側によって作られた、この特定の取引を特定したストリングです。(そのストリングはこのコマンドに関連しているコマンドと応答で構成されます)。 トランザクション識別子はコマンド記述でtidが簡略化されています。 トランザクション識別子は長さが15のキャラクタに制限されます。 トランザクション識別子があらゆるコマンドとコマンド応答で必要です。
OPTIONAL ARGUMENTS
任意の議論
Many NFILE commands have "optional arguments". Optional arguments can be supplied (with appropriate values), or left out. If optional arguments are left out, their omission must be made explicit by means of substituting the empty token list in their place. The only exception to that rule is for trailing optional arguments or return values, which can be omitted without including the empty token list.
多くのNFILEコマンドには、「任意の議論」があります。 任意の議論を供給するか(適切な値で)、または省くことができます。 任意の議論を省くなら、彼らの省略をそれらの場所で空のトークンリストを代入することによる明白にしなければなりません。 その規則への唯一の例外が引きずっている任意の議論かリターン値のためのものです。(空のトークンリストを含んでいなくて、値を省略できます)。
For example, the text of the DELETE command description explains that either a handle or a pathname must be supplied, but not both; therefore, one of them is an optional argument. Here is the command format of DELETE:
例えば、DELETEコマンド記述のテキストは、ハンドルかパス名のどちらかを供給しなければならないと説明しますが、ともに説明するというわけではありません。 したがって、それらの1つは任意の議論です。 ここに、DELETEのコマンド形式があります:
(DELETE tid handle pathname)
(DELETE tidハンドルパス名)
Greenberg & Keene [Page 11] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[11ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
If you supply a handle and no pathname, the command format is:
ハンドルを供給しますが、あなたがどんなパス名も供給しないなら、コマンド形式が以下の通りです。
(DELETE tid handle)
(DELETE tidハンドル)
If you supply a pathname and no handle, the command format is:
パス名を供給しますが、あなたがどんなハンドルも供給しないなら、コマンド形式が以下の通りです。
(DELETE tid empty-token-list pathname)
(DELETE tid空のトークンリストパス名)
The empty token list in the token list stream appears as a LIST-BEGIN followed immediately by a LIST-END.
LIST-BEGINがすぐにLIST-ENDで続いたので、トークンリストストリームにおける空のトークンリストは現れます。
OPTIONAL KEYWORD/VALUE PAIRS
任意のキーワード/値の組
Four NFILE commands have "optional keyword/value pairs". These commands are: COMPLETE, LOGIN, OPEN, and READ. Optional keyword/value pairs can be either included in the command or omitted entirely. There is no need to substitute the empty token list for ommitted optional keyword tokens, unlike optional arguments. The order of the option keyword/value pairs is not significant.
4つのNFILEコマンドには、「任意のキーワード/値の組」があります。 これらのコマンドは以下の通りです。 完全であることで、ログインしてください、そして、開いてください、そして、読んでください。 任意のキーワード/値の組をコマンドに含んでいるか、または完全に省略できます。 空のトークンリストを任意の議論と異なったommitted任意のキーワードトークンの代わりに用いる必要は全くありません。 オプションキーワード/価値の組の注文は重要ではありません。
If included, optional keyword/value pairs are a sequence of alternating keywords and values. The values associated with the keywords can be keywords, lists, strings, Booleans, integers, dates, date-or-never's, and time intervals. The text of each command description states what type of value is appropriate for each optional keyword.
含まれているなら、任意のキーワード/値の組はキーワードと値を交替する系列です。 キーワードに関連している値がキーワード、リスト、ストリングであるかもしれない、Booleans(整数)がデートする、決してデートしないでください、そして、時間間隔。 それぞれのコマンド記述のテキストは、それぞれの任意のキーワードに、どんなタイプの価値が適切であるかを述べます。
Optional keyword/value pairs appear in the text as the keyword only, in uppercase letters. For example, here is the format of the LOGIN command:
任意のキーワード/値の組はキーワードだけとしてのテキスト、大文字に現れます。 例えば、ここに、LOGINコマンドの形式があります:
Command Format:
書式を命令してください:
(LOGIN tid user password FILE-SYSTEM USER-VERSION)
(LOGIN tidユーザパスワードFILE-SYSTEM USER-バージョン)
FILE-SYSTEM and USER-VERSION are two optional keywords associated with the LOGIN command. The user side can supply USER-VERSION, and omit FILE-SYSTEM as shown in this example:
FILE-SYSTEMとUSER-バージョンはLOGINコマンドに関連している2つの任意のキーワードです。 ユーザ側は、この例に示されるようにUSER-バージョンを供給して、FILE-SYSTEMを省略できます:
(LOGIN x105 tjones let-me-in USER-VERSION 2)
(私を入れているLOGIN x105 tjones USER-バージョン2)
As seen above, the optional keyword/value pair USER-VERSION, if supplied in a command, consists of the keyword USER-VERSION followed by the value to be used for that keyword (in this example, 2).
上が見られるように、コマンドで供給するなら、任意のキーワード/値の組USER-バージョンは値があとに続いた、そのキーワード(この例の2)に使用されたキーワードUSER-バージョンから成ります。
Greenberg & Keene [Page 12] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[12ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
7.3 Data Channel Handles and Direct File Identifiers
7.3 データ・チャンネルハンドルと直接編成ファイル識別子
Several NFILE commands require an argument that specifies an opening. This kind of argument is called a handle in the command description. It is always a string type argument. A handle can be either a data channel handle or a direct file identifier, depending on the mode of the opening:
いくつかのNFILEコマンドが始まりを指定する議論を必要とします。 この種類の議論はコマンド記述でハンドルと呼ばれます。 いつもそれはストリングタイプ議論です。 ハンドルは、データ・チャンネルハンドルか直接編成ファイル識別子のどちらかであるかもしれません、始まりのモードによって:
Data Stream
データ・ストリーム
The handle must identify a data channel that is bound to an opening.
ハンドルは始まりに縛られるデータ・チャンネルを特定しなければなりません。
Direct Access
直接アクセス
In general, the handle must be a direct file identifier. A direct file identifier specifies a direct access opening. It is the same as the value supplied in the DIRECT-FILE-ID keyword/value pair in the OPEN command. It is used for all operations that identify an opening rather than a data channel.
一般に、ハンドルは直接編成ファイル識別子であるに違いありません。 直接編成ファイル識別子は直接アクセス始まりを指定します。 それはオープン命令でDIRECT-FILE-IDキーワード/価値の組で供給された値と同じです。 それはデータ・チャンネルよりむしろ始まりを特定するすべての操作に使用されます。
Two NFILE commands applicable to direct access openings are exceptions to the general rule. The handle supplied in ABORT and CONTINUE cannot be a direct file identifier, but must be a data channel handle instead.
アクセス始まりを向けるのにおいて適切な2つのNFILEコマンドが一般的な規則への例外です。 ABORTとCONTINUEで供給されたハンドルは、直接編成ファイル識別子であることができませんが、代わりにデータ・チャンネルハンドルであるに違いありません。
7.4 Syntax of File and Directory Pathname Arguments
ファイルとディレクトリパス名議論の7.4構文
Some arguments and return values in the NFILE command descriptions represent file pathnames. These are strings in the pathname syntax native to the server host. These pathnames contain no host identifiers of any kind. These pathnames must be fully defaulted, in the sense that they have a directory and file name (and file type, if the server operating system supports file types). If appropriate, a device is referenced in the pathname. If the server file system supports version numbers, there is always an explicit version number, even if that number or other specification is that system's representation of "newest" or "oldest".
NFILEコマンド記述におけるいくつかの議論とリターン値はファイルパス名を表します。 サーバー・ホスト固有のパス名構文でこれらはストリングです。 これらのパス名はどんな種類に関するホスト識別子も全く含んでいません。 これらのパス名は完全にそうであるに違いありません。それらにはディレクトリとファイル名があるという(サーバオペレーティングシステムがファイルの種類をサポートするなら、タイプをファイルしてください)意味で、デフォルトとしました。 適切であるなら、デバイスはパス名で参照をつけられます。 サーバファイルシステムがバージョン番号をサポートするなら、明白なバージョン番号がいつもあります、その数か他の仕様がそのシステムの「最も新しい」か「最も古いこと」の表現であっても。
Greenberg & Keene [Page 13] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[13ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
Here are some examples of file pathnames, for different server hosts:
ここに、異なったサーバー・ホストのためのファイルパス名に関するいくつかの例があります:
Server Host Example of File Pathname
ファイルパス名に関するサーバー・ホストの例
------------------------------------------------------------
------------------------------------------------------------
UNIX /usr/max/life.c
UNIX/usr/max/life.c
TOPS-20 ps:<max>life.bin.17
TOPS-20 ps: <最大>life.bin.17
VMS MACD:[MAX]LIFE.FOR;3
VMS MACD: [マックス]LIFE.FOR; 3
Symbolics LMFS >max>life.lisp.newest
信条学LMFS>最大>life.lisp.newest
------------------------------------------------------------
------------------------------------------------------------
The CREATE-DIRECTORY and HOME-DIRECTORY commands take a directory as an argument. In NFILE commands, a directory is represented by a string that names the directory. In most cases this string is in the syntax native to the server host. However in some cases the native format is modified somewhat to clarify that the string names a directory, and not a file. For example, a directory on UNIX is represented by "/usr/max/", not "/usr/max".
CREATE-ディレクトリとホームディレクトリコマンドは議論としてディレクトリをみなします。 NFILEコマンドで、ディレクトリはディレクトリを命名するストリングによって表されます。 多くの場合、このストリングはサーバー・ホスト固有の構文であります。 ネイティブの形式がそれをはっきりさせるようにどんなにいくつかの場合いくらか変更されても、ストリングはファイルではなく、ディレクトリを命名します。 例えば、UNIXの上のディレクトリは"/usr/max"ではなく"/usr/max/"によって表されます。
Here are some examples of directory pathnames for different server hosts:
ここに、異なったサーバー・ホストのためのディレクトリパス名に関するいくつかの例があります:
Server Host Example of Directory Pathname
ディレクトリパス名に関するサーバー・ホストの例
------------------------------------------------------------
------------------------------------------------------------
UNIX /usr/max/
UNIX/usr/max/
TOPS-20 <max>
先端-20<最大>。
VMS MACD:[MAX]
VMS MACD:[マックス]
Symbolics LMFS >max>hacks>
信条学LMFS>最大>は>をハックします。
------------------------------------------------------------
------------------------------------------------------------
7.5 Format of NFILE File Property/Value Pairs
7.5 NFILEファイル特性/価値のペアの形式
Several NFILE commands request information regarding the properties of files or directories. These commands include: DIRECTORY, MULTIPLE-FILE-PLISTS, PROPERTIES, and CHANGE-PROPERTIES. This section describes how file property information is conveyed over the token list stream.
いくつかのNFILEコマンドがファイルかディレクトリの特性の情報を要求します。 これらのコマンドは: ディレクトリ、複数のファイルPLISTS、特性、および変化特性。 このセクションはファイル特性の情報がどう伝えられるかをトークンリストストリームに説明します。
Greenberg & Keene [Page 14] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[14ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
File property information is usually sent in property/value pairs, where the property identifies the property, and the following value gives the value of that property for the specified file.
通常、特性/値の組でファイル特性の情報を送ります、そして、以下の値は指定されたファイルのためにその属性の価値を与えます。(そこでは、特性が特性を特定します)。
Each property is denoted either by a keyword or an integer. You can mix both ways of specifying properties (keyword or integer) within a single description. An integer is interpreted as an index into the Property Index Table, an array of property keywords. The server can optionally send a Property Index Table to the user during the execution of the LOGIN command, although it is not required. This greatly reduces the length of transmissions.
各特性はキーワードか整数によって指示されます。 あなたはただ一つの記述の中で特性(キーワードか整数)を指定する両方の方法を混ぜることができます。 整数はインデックスとしてProperty Index Table、特性のキーワードの勢ぞろいに解釈されます。 サーバはLOGINコマンドの実行の間、任意にProperty Index Tableをユーザに送ることができます、それが必要ではありませんが。 これはトランスミッションの長さを大いに減少させます。
In command arguments, file properties cannot be specified with integers; keywords must be used to specify file properties in command arguments. Integers can be used to denote file properties only in command responses.
コマンド議論では、整数でファイルの特性を指定できません。 コマンド議論でファイルの特性を指定するのにキーワードを使用しなければなりません。 コマンド応答だけでファイルの特性を指示するのに整数を使用できます。
We now list the keywords associated with file properties. This list is not intended to be restrictive. If a programmer implementing NFILE needs a new keyword, a new keyword (not on this list) can be invented. The type of value of any new keywords is by default string. The keywords are sorted here by conceptual data type:
私たちは現在、ファイルの特性に関連しているキーワードをリストアップします。 このリストが制限していることを意図しません。 NFILEを実装するプログラマが新しいキーワードを必要とするなら、新しいキーワード(このリストでないところの)を発明できます。 どんな新しいキーワードの価値のタイプもデフォルトでそうです。ストリング。 キーワードはここで概念的なデータ型によって分類されます:
Data type Keywords denoting file properties
ファイルの特性を指示するデータ型Keywords
----------------------------------------------------------------
----------------------------------------------------------------
Integers BLOCK-SIZE, BYTE-SIZE, GENERATION-RETENTION-COUNT,
LENGTH-IN-BLOCKS, LENGTH-IN-BYTES,
DEFAULT-GENERATION-RETENTION-COUNT
整数ブロック・サイズ、バイトサイズ、世代保有カウント、ブロックの長さ、バイトで表現される長さ、デフォルト世代保有カウント
Dates CREATION-DATE, MODIFICATION-DATE
日付の作成日付、変更日付
Date-or-never's REFERENCE-DATE, INCREMENTAL-DUMP-DATE,
COMPLETE-DUMP-DATE, DATE-LAST-EXPUNGED,
EXPIRATION-DATE
決してデートしないでください、参照日付、増加のダンプ期日、完全なダンプ期日、最後に梢消された日付、有効期限
Time intervals AUTO-EXPUNGE-INTERVAL
時間間隔AUTO-EXPUNGE-INTERVAL
Keyword Lists SETTABLE-PROPERTIES, LINK-TRANSPARENCIES,
DEFAULT-LINK-TRANSPARENCIES
キーワードリストのSETTABLE-特性、リンク透明、デフォルトリンク透明
Boolean values DELETED, DONT-DELETE, DONT-DUMP, DONT-REAP,
SUPERSEDE-PROTECT, NOT-BACKED-UP, OFFLINE,
TEMPORARY, CHARACTERS, DIRECTORY
ブール値DELETED、ドント-DELETE、ドント-DUMP、ドント-REAP、SUPERSEDE-PROTECT、BACKED-UPでない、OFFLINE、TEMPORARY、キャラクター、ディレクトリ
Greenberg & Keene [Page 15] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[15ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
Strings ACCOUNT, AUTHOR, LINK-TO, PHYSICAL-VOLUME,
PROTECTION, VOLUME-NAME, PACK-NUMBER, READER,
DISK-SPACE-DESCRIPTION, and any keywords not
on this list
ACCOUNT、AUTHOR、LINK-TO、PHYSICAL-VOLUME、PROTECTION、VOLUME-NAME、PACK-NUMBER、読者、DISK-SPACE-記述、およびこのリストの上のどんなキーワードも結びます。
Note that these keyword names are intended to imply the semantics of the properties. For a discussion of the semantics of CREATION-DATE: See the section "NFILE OPEN Response Return Values", section 8.20.2. The "Reference Guide to Streams, Files, and I/O" in the Symbolics documentation set details the semantics that Symbolics associates with these properties.
これらのキーワード名が特性の意味論を含意することを意図することに注意してください。 CREATION-日付:の意味論の議論のために 「NFILE OPEN応答リターン値」というセクション、セクション8.20.2を見てください。 Symbolicsドキュメンテーションセットの「ストリーム、ファイル、および入出力への参照ガイド」はSymbolicsがこれらの特性に関連づける意味論を詳しく述べます。
8. NFILE COMMANDS
8. NFILEコマンド
It is important to understand the conventions used in each of the following command descriptions. See the section "Conventions Used in This Document", section 7.
それぞれの以下のコマンド記述に使用されるコンベンションを理解しているのは重要です。 「本書では使用されるコンベンション」というセクション、セクション7を見てください。
8.1 ABORT Command
8.1 中止コマンド
Command: (ABORT tid input-handle)
コマンド: (ABORT tid入力ハンドル)
Response: (ABORT tid)
応答: (ABORT tid)
ABORT cleanly interrupts and prematurely terminates a single direct access mode data transfer initiated with READ. The required input- handle string argument identifies a data channel on which an input transfer is currently taking place; this must be a direct access transfer. input-handle must identify a data channel; it cannot be a direct file identifier.
ABORTは清潔に中断して、早まって、READと共に着手されたただ一つの直接アクセスモードデータ転送を終えます。 必要な入力ハンドルストリング議論は入力転送が現在起こっているデータ・チャンネルを特定します。 これは直接アクセス転送であるに違いありません。入力ハンドルはデータ・チャンネルを特定しなければなりません。 それは直接編成ファイル識別子であるはずがありません。
Upon receiving the ABORT command, the server checks to see if a transfer is still active on that channel. If so, the server terminates the transfer by telling the data connection logical process to stop transferring bytes of data. The user side needs to issue this command only when there are outstanding unread bytes. This excludes the case of the data channel having been disestablished or reallocated by the user side.
ABORTコマンドを受け取ると、サーバは、転送がそのチャンネルでまだ活発であるかどうか確認するためにチェックします。 そうだとすれば、バイトのデータを移すのを止めるようにデータの接続の論理的なプロセスに言うことによって、サーバは転送を終えます。 ユーザ側は、傑出している読まれていないバイトがあるときだけ、このコマンドを発行する必要があります。 これはユーザ側を廃止されるか、または再割当てされたデータ・チャンネルのケースを除きます。
Whether or not a transfer is active on that channel, the user side puts the data channel into the unsafe state. Before the data channel can be used again, it must be resynchronized.
転送がそのチャンネルで活発であるか否かに関係なく、ユーザ側は危険な状態にデータ・チャンネルを入れます。 再びデータ・チャンネルを使用できる前に、それは再連動しなければなりません。
8.2 CHANGE-PROPERTIES Command
8.2 変化特性のコマンド
Command: (CHANGE-PROPERTIES tid handle pathname property-pairs)
コマンド: (CHANGE-PROPERTIES tidハンドルパス名特性組)
Response: (CHANGE-PROPERTIES tid)
応答: (CHANGE-PROPERTIES tid)
Greenberg & Keene [Page 16] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[16ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
CHANGE-PROPERTIES changes one or more properties of a file. Either a handle or a pathname must be given, but not both. Whichever one is given must be supplied as a string. handle identifies a data channel that is bound to an open file; it can be a direct file identifier. pathname identifies a file on the server machine.
CHANGE-PROPERTIESはファイルの1つ以上の資産を変えます。 ハンドルかパス名のどちらかを与えますが、ともに与えてはいけません。 ストリングとして与えられているどの供給しなければならないか。ハンドルはオープン・ファイルに縛られるデータ・チャンネルを特定します。 それは直接編成ファイル識別子であるかもしれません。パス名はサーバマシンのファイルを特定します。
property-pairs is a required token list of keyword/value pairs, where the name of the property to be changed is the keyword, and the desired new property value is the value.
特性組はキーワード/値の組の必要なトークンリストです。そこでは、変えられるべき特性の名前がキーワードであり、必要な新しい資産価値は値です。
The properties that can be changed are host-dependent, as are any restrictions on the values of those properties. The properties that can be changed are the same as those returned as settable-properties, in the command response for the PROPERTIES command.
変えることができる資産はどんな制限のようにもホストそれらの特性の値に依存しています。 変えることができる資産はそれらが「舗装用敷石-可能」-特性として戻ったのと同じです、PROPERTIESコマンドのためのコマンド応答で。
The server tries to modify all the properties listed in property- pairs to the desired new values. There is currently no definition about what should be done if the server can successfully change some properties but not others.
サーバは特性の組で必要な新しい値に記載されたすべての特性を変更しようとします。 現在、サーバが首尾よく他のものではなく、いくつかの資産を変えることができるなら何をするべきであるかに関して定義が全くありません。
For further information on file property keywords and associated values: See the section "Format of NFILE File Property/Value Pairs", section 7.5.
ファイル特性のキーワードと関連値に関する詳細のために: 「NFILEファイル特性/価値のペアの形式」というセクション、セクション7.5を見てください。
8.3 CLOSE Command
8.3 閉鎖コマンド
Command: (CLOSE tid handle abort-p)
コマンド: (CLOSE tidはアボートpを扱います)
Response: (CLOSE tid truename binary-p other-properties)
応答: (CLOSE tid truenameの2進のp他の特性)
CLOSE terminates a data transfer, and frees a data channel. The handle must be a data channel handle for a data stream opening, or a direct file identifier for a direct access opening. If a data channel is given, a transfer must be active on that handle. If abort-p is supplied as Boolean truth, the file is close-aborted, as described below.
CLOSEはデータ転送を終えて、データ・チャンネルを解放します。 ハンドルは、データ・ストリーム始まりへのデータ・チャンネルハンドル、または直接アクセス始まりのための直接編成ファイル識別子でなければなりません。 データ・チャンネルを与えるなら、転送はそのハンドルで活発であるに違いありません。 ブール真実としてアボートpを供給するなら、ファイルは以下で説明されるように近くで中止になります。
"Closing the file" has different implications specific to each operating system. It generally implies invalidation of the pointer or logical identifier obtained from the operating system when the file was "opened", and freeing of operating system and/or job resources associated with active file access. For output files, it involves ensuring that every last bit sent by the user has been successfully written to disk. The server should not send a successful response until all these things have completed successfully.
「ファイルを閉じます」で、異なった意味は各オペレーティングシステムに特定になります。 一般に、それは無効にするファイルが「開かれた」ときオペレーティングシステムから得られた指針か論理的な識別子について、および活発なファイルアクセスに関連しているオペレーティングシステム、そして/または、仕事のリソースの解放を含意します。 出力ファイルに関しては、それは、ユーザによって送られた最後のあらゆるビットが首尾よくディスクに書かれているのを確実にすることを伴います。 サーバはこれらのものが首尾よく完成したすべてまでうまくいっている応答を送るべきではありません。
Greenberg & Keene [Page 17] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[17ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
In either data stream or direct access mode, the user can request the server to close-abort the file, instead of simply closing it. To close-abort a file means to close it in such a way, if possible, that it is as if the file had never been opened. In the specific case of a file being created, it must appear as if the file had never been created. This might be more difficult to implement on certain operating systems than others, but tricks with temporary names and close-time renamings by the server can usually be used to implement close-abort in these cases. In the case of a file being appended to, close-abort means to forget the appended data.
データ・ストリームか直接アクセスモードのどちらかで、ユーザは、ファイルを閉鎖して中止するようサーバに要求できます、単にそれを閉じることの代わりに。 それができれば、そのような方法でそれを閉じるファイル手段ですが、まるでファイルが一度も開かれたことがなかったかのように閉鎖して中止になるように。 作成されるファイルの特定の場合では、まるでファイルが一度も作成されたことがなかったかのように見えなければなりません。 これはあるオペレーティングシステムで実装するのが他のものより難しいかもしれませんが、通常、これらの場合における厳密なアボートを実装するのにサーバによる一時的な名前と近い時間再命名があるトリックを使用できます。 aに関するケースが追加された存在をファイルするコネ、厳密なアボートは、追加されたデータを忘れることを意味します。
AN UNSUCCESSFUL CLOSE OPERATION
失敗の厳密な操作
For the normal CLOSE operation (not a close-abort), after writing every last bit sent by the user to disk, and before closing the file, the server checks the data channel specified by handle to see if an asynchronous error is outstanding on that channel. That is, the server must determine whether it has sent an asynchronous error description to the user, to which the user has not yet responded with a CONTINUE command. If so, the server is unable to close the file, and therefore sends a command error response indicating that an error is pending on the channel. The appropriate three-letter error code is EPC. See the section "NFILE Errors and Notifications", section 10.
ディスクと、ファイルを閉じるユーザによって送られた最後のあらゆるビット前に書いた後に、通常のCLOSE操作(厳密なアボートでない)がないかどうか、サーバはハンドルによって指定された、非同期な誤りがそのチャンネルで傑出しているかどうかわかったデータ・チャンネルをチェックします。 すなわち、サーバは、それが非同期なエラー記述をユーザに送ったかどうか決定しなければなりません。(ユーザはCONTINUEコマンドでまだそのユーザに応じていません)。 そうだとすれば、サーバで、ファイルを閉じることができないで、したがって、コマンド誤り応答は、誤りがチャンネルに未定であることを示します。 適切な3文字のエラーコードはEPCです。 「NFILE誤りと通知」というセクション、セクション10を見てください。
A SUCCESSFUL CLOSE OPERATION
うまくいっている厳密な操作
The return values for OPEN and CLOSE are syntactically identical, but the values might change between the time of the file being opened and when it is closed. For example, the truename return value is supplied after all the close-time renaming of output files is done and the version numbers resolved (for operating systems supporting version numbers). Therefore, on some systems the truename of a file has one value at the time it is opened, and a different value when it has been closed. For a description of the CLOSE return values: See the section "NFILE OPEN Response Return Values", section 8.20.2.
オープンとCLOSEのためのリターン値はシンタクス上同じですが、値は開かれるファイルの時間、それが閉じられる時変化するかもしれません。 例えば、出力ファイルの改名が完了していて、バージョン番号が決議した(バージョン番号をサポートするオペレーティングシステムのために)すべての近い時の後にtruenameリターン価値を供給します。 したがって、それが開かれて、それであるときに異価が閉じられたとき、いくつかのシステムの上では、ファイルのtruenameは1つの値を持っています。 CLOSEの記述には、値を返してください: 「NFILE OPEN応答リターン値」というセクション、セクション8.20.2を見てください。
If the user gives the CLOSE command with abort-p supplied as Boolean truth, thus requesting a close-abort of the file, the server need not check whether an asynchronous error description is outstanding on the channel. The server simply close-aborts the file.
ユーザがアボートpとのコマンドがブールとして供給したCLOSEに真実を与えて、その結果、ファイルの厳密なアボートを要求する場合、サーバは、非同期なエラー記述がチャンネルで傑出しているかどうかチェックする必要はありません。 サーバは単にファイルを閉鎖して中止します。
Greenberg & Keene [Page 18] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[18ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
8.4 COMPLETE Command
8.4 完全なコマンド
Command: (COMPLETE tid string pathname DIRECTION NEW-OK DELETED)
コマンド: (COMPLETE tidストリングパス名DIRECTION NEW-OK DELETED)
Response: (COMPLETE tid new-string success)
応答: (COMPLETE tid新しいストリング成功)
COMPLETE performs file pathname completion.
COMPLETEはファイルパス名完成を実行します。
string is a partial filename typed by the user and pathname is the default name against which it is being typed. Both string and pathname are required arguments, and are of type string. The remaining arguments are optional keyword/value pairs.
ストリングはユーザとパス名によってタイプされた部分的なファイル名がそれがタイプされているデフォルト名であるということです。 ストリングとパス名の両方が、必要な議論であり、タイプストリングでできています。 残っている議論は任意のキーワード/値の組です。
NEW-OK is Boolean; if followed by Boolean truth, the server should allow either a file that already exists, or a file that does not yet exist. The default of NEW-OK is false; that is, the server does not consider files that do not already exist.
NEW-OKはブールです。 ブール真実があとに続いているなら、サーバは既に存在するファイルかまだ存在していないファイルのどちらかを許容するべきです。 NEW-OKデフォルトは誤っています。 すなわち、サーバは既に存在しないファイルを考えません。
DELETED is a Boolean type argument; if followed by Boolean truth, the server is instructed to look for files that have been deleted but not yet expunged, as well as non-deleted files. The default is to ignore soft-deleted files.
DELETEDはブールタイプ議論です。 ブール真実があとに続いているなら、サーバが削除されますが、まだ梢消されていないファイルを探すよう命令されます、非削除されたファイルと同様に。 デフォルトは柔らかい削除されたファイルを無視することです。
DIRECTION can be followed by READ, to indicate that the file is to be read. If the file is to be written, DIRECTION can be followed by WRITE. The default is READ.
READは、ファイルが読まれることであることを示すためにDIRECTIONに続くことができます。 ファイルが書かれていることであるなら、WRITEはDIRECTIONに続くことができます。 デフォルトはREADです。
The filename is completed according to the files present in the host file system, and the expanded string new-string is returned. New- string is always a string containing a file name: either the original string, or a new, more specific string. The value of success indicates the status of the completion. The keyword value OLD or NEW means complete success, whereas the empty token list means failure. The following values of success are possible:
ホストファイルシステムの現在のファイル、および新しいストリングが返される拡張ストリングに従って、ファイル名は完成します。 いつも新しいストリングはファイル名を含むストリングです: オリジナルのストリングか新しくて、より特定のストリングのどちらか。 成功の値は完成の状態を示します。 キーワード価値のOLDかNEWが完全な成功を意味しますが、空のトークンリストは失敗を意味します。 成功の以下の値は可能です:
Value Meaning
値の意味
----------------------------------------------------------------
----------------------------------------------------------------
OLD Success: the string completed to the name of
a file that exists.
古い成功: 存在するファイルの名前に完成したストリング。
NEW Success: the string completed to the name of
a file that could be created.
新しい成功: 作成できたファイルの名前に完成したストリング。
Empty token list Failure due to one of these reasons:
これらの1つによる空のトークンリストFailureは推論します:
The file is on a file system that does not
そうしないファイルシステムの上にファイルがあります。
Greenberg & Keene [Page 19] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[19ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
support completion. new-string is supplied as
the unchanged string.
完成をサポートしてください。変わりのないストリングとして新しいストリングを供給します。
There is no possible completion. new-string
is supplied as the unchanged string.
どんな可能な完成もありません。変わりのないストリングとして新しいストリングを供給します。
There is more than one possible completion.
The given string is completed up to the first
point of ambiguity, and the result is supplied
as new-string.
1つ以上の可能な完成があります。 与えられたストリングをあいまいさの最初のポイントまで完成します、そして、新しいストリングとして結果を供給します。
A directory name was completed. Completion
was not successful because additional
components to the right of this directory
remain to be specified. The string is
completed through the directory name and the
delimiter that follows it, and the result is
returned in new-string.
ディレクトリ名は完成しました。 このディレクトリの右への追加コンポーネントが指定されるために残っているので、完成はうまくいきませんでした。 ストリングはディレクトリ名とそれに続くデリミタを通して完成します、そして、結果は新しいストリングで返されます。
The semantics of COMPLETE are not documented here. See the "Reference Guide to Streams, Files, and I/O" in the Symbolics documentation set for the recommended semantics of COMPLETE.
COMPLETEの意味論はここに記録されません。 Symbolicsドキュメンテーションの「ストリーム、ファイル、および入出力への参照ガイド」がCOMPLETEのお勧めの意味論のためにセットするのを見てください。
8.5 CONTINUE Command
8.5 続行コマンド
Command: (CONTINUE tid handle)
コマンド: (CONTINUE tidハンドル)
Response: (CONTINUE tid)
応答: (CONTINUE tid)
CONTINUE resumes a data transfer that was temporarily suspended due to an asynchronous error. Each asynchronous error description has an optional argument of RESTARTABLE, indicating whether it makes any sense to try to continue after this particular error occurred. CONTINUE tries to resume the data transfer if the error is potentially recoverable, according to the RESTARTABLE argument in the asynchronous error description. For a discussion of asynchronous errors: See the section "NFILE Errors and Notifications", section 10.
CONTINUEは非同期な誤りのため一時中断したデータ転送を再開します。 それぞれの非同期なエラー記述には、RESTARTABLEの任意の議論があります、それが何か続こうとするこの後の意味を特別の誤りにするかどうかが起こったのを示して。 誤りが潜在的に回復可能であるなら、CONTINUEはデータ転送を再開しようとします、非同期なエラー記述におけるRESTARTABLE議論に従って。 非同期な誤りの議論のために: 「NFILE誤りと通知」というセクション、セクション10を見てください。
handle is a required string-type argument that refers to the handle of the data channel that received an asynchronous error. That data channel could have been in use for a data stream or direct access transfer. handle cannot be a direct file identifier.
ハンドルは非同期な誤りを受けたデータ・チャンネルのハンドルについて言及する必要なストリングタイプ議論です。 データ・ストリームか直接アクセス転送に、そのデータ・チャンネルは使用中であったかもしれません。ハンドルは直接編成ファイル識別子であるはずがありません。
If the asynchronous error description does not contain the RESTARTABLE argument, and the user issues the CONTINUE command anyway, the server gives a command error response.
非同期なエラー記述がRESTARTABLE議論を含んでいなくて、ユーザがとにかくCONTINUEコマンドを発行するなら、サーバはコマンド誤り応答を与えます。
Greenberg & Keene [Page 20] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[20ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
8.6 CREATE-DIRECTORY Command
8.6 ディレクトリを作成しているコマンド
Command: (CREATE-DIRECTORY tid pathname property-pairs)
コマンド: (CREATE-ディレクトリtidパス名特性組)
Response: (CREATE-DIRECTORY tid dir-truename)
応答: (CREATE-ディレクトリtid dir-truename)
CREATE-DIRECTORY creates a directory on the remote file system. The required pathname argument is a string identifying the pathname of the directory to be created. The return value dir-truename is the pathname of the directory that was successfully created. Both of these pathnames are directory pathnames: See the section "Syntax of File and Directory Pathname Arguments", section 7.4.
CREATE-ディレクトリはリモートファイルシステムにディレクトリを作成します。 必要なパス名議論は作成されるためにディレクトリのパス名を特定するストリングです。 リターン価値のdir-truenameは首尾よく作成されたディレクトリのパス名です。 これらのパス名の両方がディレクトリパス名です: 「ファイルとディレクトリパス名議論の構文」というセクション、セクション7.4を見てください。
property-pairs is a keyword/value list of properties that further define the attributes of the directory to be created. The allowable keywords and associated values are operating system dependent; typically they indicate arguments to be given to the native primitive for creating directories.
特性組は作成されるためにさらにディレクトリの属性を定義する特性のキーワード/値のリストです。 許容できるキーワードと関連値はオペレーティングシステムに依存しています。 通常、彼らはディレクトリを作成するのにおける、原始のネイティブに与えられている議論を示します。
If property-pairs is supplied as the empty token list, default access and creation attributes apply and should be assured by the server. See the section "Format of NFILE File Property/Value Pairs", section 7.5.
空のトークンリストとして特性組を供給するなら、デフォルトアクセスと作成属性を当てはまって、サーバは保証するべきです。「NFILEファイル特性/価値のペアの形式」というセクションを見てください、セクション7.5。
8.7 CREATE-LINK Command
8.7 リンクを作成しているコマンド
Command: (CREATE-LINK tid pathname target-pathname properties)
コマンド: (CREATE-LINK tidパス名目標パス名の特性)
Response: (CREATE-LINK tid link-truename)
応答: (CREATE-LINK tidリンク-truename)
CREATE-LINK creates a link on the remote file system.
CREATE-LINKはリモートファイルシステムにリンクを作成します。
pathname is the pathname of the link to be created; target-pathname is the place in the file system to which the link points. Both are required arguments. The return value link-truename names the resulting link.
パス名は作成されるべきリンクのパス名です。 目標パス名はリンクが指すファイルシステムの場所です。 両方が必要な議論です。 リターン価値のリンク-truenameは結果として起こるリンクを命名します。
If a server on a file system that does not support links receives the CREATE-LINK command, it sends a command error response.
リンクを支えないファイルシステムの上のサーバがCREATE-LINKコマンドを受け取るなら、それはコマンド誤り応答を送ります。
The arguments pathname and target-pathname, and the return value link-truename, are all strings in the full pathname syntax of the server host. See the section "Syntax of File and Directory Pathname Arguments", section 7.4.
サーバー・ホストの完全なパス名構文で議論パス名と目的のパス名、およびリターン価値のリンク-truenameはすべてストリングです。 「ファイルとディレクトリパス名議論の構文」というセクション、セクション7.4を見てください。
The required properties argument is a token list of keyword/value pairs. These properties and their values specify certain attributes to be given to the link. The allowable keywords and associated
必要な特性の議論はキーワード/値の組のトークンリストです。 これらの特性とそれらの値はリンクに与えられているある属性を指定します。 許容できるキーワードで関連しています。
Greenberg & Keene [Page 21] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[21ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
values are operating system dependent; typically they indicate arguments to be given to the native primitive for creating links.
値はオペレーティングシステムに依存しています。 通常、彼らはリンクを作成するのにおける、原始のネイティブに与えられている議論を示します。
If no property pairs are given in the command, the server should apply a reasonable default set of attributes to the link. See the section "Format of NFILE File Property/Value Pairs", section 7.5.
コマンドで特性の組を全く与えないなら、サーバは妥当なデフォルトセットの属性をリンクに当てはまるべきです。 「NFILEファイル特性/価値のペアの形式」というセクション、セクション7.5を見てください。
8.8 DATA-CONNECTION Command
8.8 データ接続命令
Command: (DATA-CONNECTION tid new-input-handle new-output-handle)
コマンド: (DATA-CONNECTION tidの新しい入力ハンドルの新しい出力ハンドル)
Response: (DATA-CONNECTION tid connection-identifier)
応答: (DATA-CONNECTION tid接続識別子)
DATA-CONNECTION enablesthe user side to initiate the establishment of a new data connection. The user side supplies two required string arguments, new-input-handle and new-output-handle. These arguments are used by subsequent commands to reference the two data channels that constitute the data connection now being created. new-input- handle describes the server-to-user data channel, and new-output- handle describes the user-to-server channel. new-input-handle and new-output-handle cannot refer to any data channels already in use.
新しいデータ接続の設立を開始するDATA-CONNECTION enablestheユーザ側。 ユーザ側は2本の必要なストリング議論、新しい入力ハンドル、および新しい出力ハンドルを供給します。 これらの議論は2つのデータが向ける参照への現在データ接続を構成する作成されるその後のコマンドで使用されます。新しい入力ハンドルはサーバから利用者データへのチャンネルについて説明します、そして、新しい出力ハンドルはユーザからサーバへのチャンネルについて説明します。新しい入力ハンドルと新しい出力ハンドルは既に使用中の少しのデータ・チャンネルにも言及できません。
Upon receiving the DATA-CONNECTION command, the server arranges for a logical port (called socket or contact name on some networks) to be made available on the foreign host machine. When the server has made that port available, it must inform the user of its identity. The server relays that information in the command response, in the required connection-identifier, a string. The server then listens on the port named by connection-identifier, and waits for the user side to connect to it.
DATA-CONNECTIONコマンドを受け取ると、サーバは、論理的なポート(いくつかのネットワークにソケットか連絡名と呼ばれる)を異種宿主マシンで利用可能にするように手配します。 そのポートがサーバで利用可能になったとき、それはアイデンティティについてユーザに知らせなければなりません。 サーバはコマンド応答、必要な接続識別子、ストリングでその情報をリレーします。 サーバは、次に、指定港で接続識別子で聴いて、ユーザ側がそれに接続するのを待っています。
Upon receiving the success command response, the user side supplies the connection-identifier to the local network implementation, in order to connect to the specified port. The data connection is not fully established until the user side connects successfully to that port. This command is unusual in that the successful command response does not signify the completion of the command; it indicates only that the server has fulfilled its responsibility in the process of establishing a data connection.
成功コマンド応答を受けると、ユーザ側は企業内情報通信網実装に接続識別子を供給します、指定されたポートに接続するために。 ユーザ側が首尾よくそのポートに接続するまで、データ接続は完全に確立されるというわけではありません。 うまくいっているコマンド応答がコマンドの完成を意味しないので、このコマンドは珍しいです。 それは、データ接続を確立することの途中にサーバが責任を実現させるだけであったのを示します。
Greenberg & Keene [Page 22] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[22ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
The connection-identifier informs the user of the correct identity of the logical port that the server has provided. NFILE expects the connection-identifier to be a string. For TCP this string is the port number represented in decimal. For Chaosnet, this string is the contact name. The connection-identifier is used only once; in all subsequent NFILE commands that need to reference either of the data channels that constitute this data connection, the new-input-handle and new-output-handle are used.
接続識別子は、サーバが提供されたことを論理的なポートの正しいアイデンティティのユーザに知らせます。 NFILEは、接続識別子がストリングであると予想します。 TCPに関しては、このストリングは小数で表されたポートナンバーです。 Chaosnetに関しては、このストリングは連絡名です。 接続識別子は一度だけ使用されます。 このデータ接続を構成するデータ・チャンネルのどちらかを参照に必要とするすべてのその後のNFILEコマンド新しい入力ハンドルと新しい出力ハンドルは使用されています。
For background information: See the section "NFILE Control and Data Connections", section 4.
基礎的な情報のために: 「NFILEコントロールとデータコネクションズ」というセクション、セクション4を見てください。
8.9 DELETE Command
8.9 削除コマンド
Command: (DELETE tid handle pathname)
コマンド: (DELETE tidハンドルパス名)
Response: (DELETE tid)
応答: (DELETE tid)
DELETE deletes a file on the remote file system.
DELETEはリモートファイルシステムでファイルを削除します。
Either a handle or a pathname must be supplied, but not both. If given, the handle must be a data channel handle for a data stream opening, or a direct file identifier for a direct access opening. pathname is a string in the full pathname syntax of the server host. See the section "Syntax of File and Directory Pathname Arguments", section 7.4.
ハンドルかパス名のどちらかを供給しますが、ともに供給してはいけません。 考えて、ハンドルは、データ・ストリーム始まりへのデータ・チャンネルハンドル、または直接アクセス始まりのための直接編成ファイル識別子でなければなりません。サーバー・ホストの完全なパス名構文でパス名はストリングです。 「ファイルとディレクトリパス名議論の構文」というセクション、セクション7.4を見てください。
With a pathname supplied, the DELETE command causes the specified file to be deleted. DELETE has different results depending on the operating system involved. That is, DELETE causes soft deletion on TOPS-20 and LMFS, and hard deletion on UNIX and Multics. If an attempt is made to delete a delete-through link on a Symbolics LMFS, its target is deleted instead.
パス名を供給していて、DELETEコマンドは指定されたファイルを削除します。 DELETEには、かかわったオペレーティングシステムに依存する異なった結果があります。 すなわち、DELETEはTOPS-20とLMFSで柔らかい削除を引き起こして、UNIXとMulticsに関して困難な削除を引き起こします。 aは-通じてリンクを削除します。削除するために試みをする、Symbolics LMFSでは、目標は代わりに削除されます。
If the handle argument is supplied to DELETE, the server deletes the open file bound to the data channel specified by handle at close time. This is true in both the output and input cases.
ハンドル議論をDELETEに供給するなら、サーバは近い時にハンドルによって指定されたデータ・チャンネルに縛られたオープン・ファイルを削除します。 これは出力と入力ケースの両方で本当です。
8.10 DIRECT-OUTPUT Command
8.10 ダイレクト出力命令
Command: (DIRECT-OUTPUT tid direct-handle output-handle)
コマンド: (DIRECT-OUTPUT tidダイレクトハンドル出力ハンドル)
Response: (DIRECT-OUTPUT tid)
応答: (DIRECT-OUTPUT tid)
DIRECT-OUTPUT starts and stops output data flow for a direct access file opening. DIRECT-OUTPUT explicitly controls binding and unbinding of an output data channel to a direct access opening.
DIRECT-OUTPUTは始まって、直接アクセスファイル・オープニングに出力データ流動を止めます。 DIRECT-OUTPUTは明らかに出力データ・チャンネルを結合と解くことを直接アクセス始まりに制御します。
Greenberg & Keene [Page 23] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[23ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
direct-handle is a required argument, and output-handle is optional.
ダイレクトハンドルは必要な議論です、そして、出力ハンドルは任意です。
If supplied, output-handle is a request to bind an output data channel (indicated by output-handle) to the direct access opening designated by the direct-handle. The specified output data channel must be free. The server binds the data channel and begins accepting data from that connection and writing it to the opening.
供給するなら、出力ハンドルは出力データ・チャンネル(出力ハンドルで、示される)をダイレクトハンドルによって指定された直接アクセス始まりまで縛るという要求です。 指定された出力データ・チャンネルは無料であるに違いありません。 サーバは、その接続とそれを書くのから始まりまでデータ・チャンネルを縛って、データを受け入れ始めます。
If the output-handle is omitted, this is a request to unbind the channel and terminate the active output transfer.
出力ハンドルが省略されるなら、これはチャンネルを解いて、活発な出力転送を終えるという要求です。
8.11 DIRECTORY Command
8.11 ディレクトリコマンド
Command: (DIRECTORY tid input-handle pathname control-keywords
properties)
コマンド: (ディレクトリtid入力ハンドルパス名コントロールキーワードの特性)
Response: (DIRECTORY tid)
応答: (ディレクトリtid)
DIRECTORY returns a directory listing including the identities and attributes for logically related groups of files, directories, and links. If the command is successful, a single token list containing the requested information is sent over the data channel specified by input-handle, and the data channel is then implicitly freed by both sides <2>. For details on the format of the token list: See the section "NFILE DIRECTORY Data Format", section 8.11.1.
ディレクトリがアイデンティティを含んでいて、リストアップされているディレクトリと属性を論理的に返す、ファイル、ディレクトリ、およびリンクの関係団体。 コマンドがうまくいくなら、求められた情報を含むただ一つのトークンリストを入力ハンドルによって指定されたデータ・チャンネルの上に送ります、そして、データ・チャンネルはその時が両側のそばでそれとなく<2>を解放したということです。 トークンの形式に関する詳細に関しては、記載してください: 「NFILE DIRECTORYデータの形式」というセクション、セクション8.11.1を見てください。
pathname specifies the files that are to be described; it is a string in the full pathname syntax of the server host. See the section "Syntax of File and Directory Pathname Arguments", section 7.4.
パス名は説明されることになっているファイルを指定します。 サーバー・ホストの完全なパス名構文でそれはストリングです。 「ファイルとディレクトリパス名議論の構文」というセクション、セクション7.4を見てください。
The pathname generally contains wildcard characters, in operating- system-specific format, describing potential file name matches. Most operating systems provide a facility that accepts such a pathname and returns information about all files matching this pathname. Some operating systems allow wildcard (potential multiple) matches in the directory or device portions of the pathname; other operating systems do not. There is no clear contract at this time about what is expected of servers on systems that do not allow wildcard matches (or some kinds of wild card matches), when presented with a wildcard.
一般に、潜在的ファイル名マッチについて説明して、パス名は操作のシステム特有の形式にワイルドカードキャラクタを含んでいます。 ほとんどのオペレーティングシステムがそのようなパス名を受け入れて、このパス名に合っているすべてのファイルの情報を返す施設を提供します。 いくつかのオペレーティングシステムがパス名のディレクトリかデバイス部分にワイルドカード(潜在的倍数)マッチを許容します。 他のオペレーティングシステムはそうしません。 このとき、何がワイルドカードマッチ(または、数種類のワイルドカードマッチ)を許容しないシステムの上でサーバに予想されるかに関してどんな明確な契約もありません、ワイルドカードを与えるとき。
properties is a token list of keywords that are the names of properties. If properties is omitted or supplied as the empty token list, the server sends along all properties. If any properties are supplied, the user is requesting the server to send only those properties.
特性は特性の名前であるキーワードのトークンリストです。 空のトークンリストとして資産を省略するか、または供給するなら、サーバはすべての資産を送ります。 何か資産を供給するなら、ユーザは、それらの資産だけを送るようサーバに要求しています。
Greenberg & Keene [Page 24] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[24ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
control-keywords ARGUMENT TO DIRECTORY
コントロールキーワードARGUMENT TO DIRECTORY
control-keywords is a token list of keywords. The control-keywords affect the way the DIRECTORY command works on the server machine. Although some of the options below request the server to limit (by some filter) the data to be returned, it is never an error if the server returns more information than is requested.
コントロールキーワードはキーワードのトークンリストです。 コントロールキーワードはディレクトリコマンドがサーバマシンに働く方法に影響します。 以下でのオプションのいくつかですが、データを制限する(あるフィルタで)サーバが返します、サーバが詳しい情報を返すならそれが要求されているより決して誤りでないということであるよう要求してください。
The following keywords are recognized:
以下のキーワードは認識されます:
DELETED
削除されます。
Includes soft-deleted files in the directory list. Without this option, they must not be included. Such files have the DELETED property indicated as true" among their properties. DELETED is ignored on systems that do not support soft deletion.
ディレクトリリストに柔らかい削除されたファイルを含んでいます。 このオプションがなければ、それらを含んではいけません。 彼らの所有地の中に「そのようなファイルには、本当であるとして示されたDELETEDの特性があります」。 DELETEDは柔らかい削除をサポートしないシステムの上で無視されます。
DIRECTORIES-ONLY
ディレクトリだけ
This option changes the semantics of DIRECTORY fairly drastically. Normally, the server returns information about all files, directories, and links whose pathnames match the supplied pathname. This means that for each file, directory, or link to be listed, its directory name must match the potentially wildcarded) directory name in the supplied pathname, its file name must match the file name in the supplied pathname, and so on.
このオプションはディレクトリの意味論をかなり抜本的に変えます。 通常、サーバはパス名が供給されたパス名に合っているすべてのファイル、ディレクトリ、およびリンクの情報を返します。 これは、記載されるべき各ファイル、ディレクトリ、またはリンクに関してディレクトリ名が潜在的にwildcardedされています) 供給されたパス名のディレクトリ名に合わなければならなくて、ファイル名が供給されたパス名、などにファイル名に合わなければならないことを意味します。
When DIRECTORIES-ONLY is supplied, the server is to list only directories, not whose pathnames match the supplied pathname, but whose pathnames expressed as directory pathnames match the (potentially wildcarded) directory portion of the supplied pathname. The description of the PROBE-DIRECTORY keyword that can be supplied as the direction argument of the OPEN command discusses this: See the section "OPEN Command", section 8.20.
サーバはディレクトリだけを供給して、ディレクトリだけをリストアップすることですが、ディレクトリパス名として表されたパス名は供給されたパス名の(潜在的にwildcardedされています)のディレクトリ部分に合っています。(ディレクトリのどんなパス名も供給されたパス名に合っていません)。 オープン命令の方向議論として提供できるPROBE-ディレクトリキーワードの記述はこれについて議論します: 「開いているコマンド」というセクション、セクション8.20を見てください。
It is not yet established what servers on hosts that do not support this type of action natively are to do when presented with DIRECTORIES-ONLY and a pathname with a wildcard directory component.
このタイプの動作をサポートしないホストの上のどんなサーバがディレクトリだけとワイルドカードディレクトリの部品があるパス名を与えるとき、ネイティブにするかことであるかはまだ設立されていません。
FAST Speeds up the operation and data transmission by not listing any properties at all for the files concerned; that is, only the truenames are returned.
関するファイルのために全く少しの特性も記載しないのによる操作とデータ伝送へのFAST Speeds。 すなわち、truenamesだけを返します。
Greenberg & Keene [Page 25] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[25ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
NO-EXTRA-INFO
付加的なインフォメーションがありません。
Specifies that the server is to suppress listing those properties that are generally more difficult or expensive to obtain. This typically eliminates listing of directory-specific properties such as information about default generation counts and expunge dates.
それらの得るために一般に、より難しいか、または高価な特性を記載しながら抑圧するためにサーバがそうであると指定します。 これはデフォルト世代カウントの情報などのディレクトリ特有の性質のリストを通常排除します、そして、日付を梢消してください。
SORTED
分類されます。
This causes the directory listing to be sorted. The sorting is done alphabetically by directory, then by file name, then file type, then file version (by increasing version number).
これは分類されるためにリストアップされているディレクトリを引き起こします。 アルファベット順に、ディレクトリでソーティングをします、次に、そして、ファイル名、ファイルの種類、当時のファイルバージョン(バージョン番号を増強するのによる)で。
8.11.1 NFILE DIRECTORY Data Format
8.11.1 NFILEディレクトリデータの形式
If the NFILE DIRECTORY command completes successfully, a single token list containing the requested directory information is sent on the data channel specified by the input-handle argument in the DIRECTORY command. This section describes the format of that single token list, and gives further detail on the properties argument to DIRECTORY.
コマンドが首尾よく完成するNFILE DIRECTORY、ただ一つのトークンが記載するなら、要求されたディレクトリ情報がデータ・チャンネルで送られる含有はディレクトリコマンドにおける入力ハンドル議論で指定しました。 このセクションは、そのただ一つのトークンリストの形式について説明して、特性の議論に関する詳細をディレクトリに与えます。
The token list is a top-level token list, so it is delimited by TOP- LEVEL-LIST-BEGIN and TOP-LEVEL-LIST-END. The top-level token list contains embedded token lists. The first embedded token list contains the empty token list followed by property/value pairs describing property information of the file system as a whole rather than of a specific file. NFILE requires one property of the file system to be present: DISK-SPACE-DESCRIPTION is a string describing the amount of free file space available on the system. The following embedded token lists contain the pathname of a file, followed by property/value pairs describing the properties of that file.
トークンリストがトップレベルトークンリストであるので、それはTOP- LEVEL-LIST-BEGINとTOP-LEVEL-LIST-ENDによって区切られます。 トップレベルトークンリストは埋め込まれたトークンリストを含んでいます。 最初の埋め込まれたトークンリストは特定のファイルについてというよりむしろ全体でファイルシステムの特性の情報について説明する特性/値の組によって従われた空のトークンリストを含んでいます。 NFILEは、ファイルシステムの1つの特性が現在であるのを必要とします: DISK-SPACE-記述はシステムの上で利用可能な自由なファイルのスペースの量について説明するストリングです。 以下の埋め込まれたトークンリストはそのファイルの特性について説明する特性/値の組によって従われたファイルのパス名を含んでいます。
The following example shows the format of the top-level token list returned by DIRECTORY, for two files. It is expected that the server return several property/value pairs for each file; the number of pairs returned is not constrained. In this example, two property/value pairs are returned for the file system, two pairs are returned for the first file, and only one pair is returned for the second file.
以下の例は2個のファイルのためにディレクトリによって返されたトップレベルトークンリストの書式を示しています。 サーバが各ファイルのために数個の特性/値の組を返すと予想されます。 返された組の数は強制的ではありません。 この例では、ファイルシステムのために2特性/値の組を返します、そして、最初のファイルのために2組を返します、そして、2番目のファイルのために1組だけを返します。
TOP-LEVEL-LIST-BEGIN
LIST-BEGIN - first embedded token list starts
LIST-BEGIN - an empty embedded token list starts
LIST-END - the empty embedded token list ends
prop1 value1 - property/value pairs of file system
prop2 value2
LIST-END
TOP-LEVEL-LIST-BEGIN LIST-BEGIN--最初の埋め込まれたトークンリストはLIST-BEGINを始動します--空の埋め込まれたトークンリストは空の埋め込まれたトークンリストがprop1 value1を終わらせるという特性/値が対にするファイルシステムprop2 value2 LIST-ENDのLIST-ENDを始動します。
Greenberg & Keene [Page 26] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[26ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
LIST-BEGIN
pathname1 - pathname of the first file
prop1 value1 - property/value pairs of first file
prop2 value2
LIST-END
LIST-BEGIN
pathname2 - pathname of the second file
prop1 value1 - property/value pairs of second file
LIST-END
TOP-LEVEL-LIST-END
最初に、LIST-BEGIN pathname1--最初のファイルprop1 value1のパス名--特性/値の組のファイルprop2 value2 LIST-END LIST-BEGIN pathname2--2番目のファイルprop1 value1のパス名--第2ファイルLIST-END TOP-LEVEL-LIST-ENDの特性/値の組
The following example is designed to illustrate the structure of the top-level token list by depicting TOP-LEVEL-LIST-BEGIN and TOP- LEVEL-LIST-END by parentheses and LIST-BEGIN and LIST-END by squarbe rackets. respectively. The indentation, blank spaces, and newlines in the example are not part of the token list, but are used here to make the structure of the token list clear.
以下の例は、squarbeで括弧、LIST-BEGIN、およびLIST-ENDでTOP-LEVEL-LIST-BEGINとTOP- LEVEL-LIST-ENDについて表現することによって最高レベルトークンリストの構造を例証するように設計されています。ラケットそれぞれ。 刻み目、空白の空間、および例のニューラインは、トークンリストの一部ではありませんが、トークンリストの構造を明らかにするのにここで使用されます。
([ [ ] prop1 value1 prop2 value2]
[pathname1 prop1 value1 prop2 value2]
[pathname2 prop1 value1])
([ [ ]prop1 value1 prop2 value2] [pathname1 prop1 value1 prop2 value2][pathname2 prop1 value1)
The pathname is a string in the full pathname syntax of the server host. See the section "Syntax of File and Directory Pathname Arguments", section 7.4.
サーバー・ホストの完全なパス名構文でパス名はストリングです。 「ファイルとディレクトリパス名議論の構文」というセクション、セクション7.4を見てください。
For further information on file property/value pairs: See the section "Format of NFILE File Property/Value Pairs", section 7.5.
ファイルの詳細に関しては、特性/値は対にされます: 「NFILEファイル特性/価値のペアの形式」というセクション、セクション7.5を見てください。
8.12 DISABLE-CAPABILITIES Command
8.12 能力を無効にしているコマンド
Command: (DISABLE-CAPABILITIES tid capability)
コマンド: (DISABLE-CAPABILITIES tid能力)
Response: (DISABLE-CAPABILITIES tid cap-1 success-1
cap-2 success-2 cap-3 success-3 ...)
応答: (DISABLE-CAPABILITIES tid上限-1成功-1上限-2成功-2上限-3成功-3)
DISABLE-CAPABILITIES causes an access capability to be disabled on the server machine. capability is a string naming the capability to be disabled. The meaning of the capability is dependent on the operating system.
DISABLE-CAPABILITIESはサーバマシンの上で無効にするべきアクセス能力を引き起こします。能力は無効にするべき能力を命名するストリングです。 能力の意味はオペレーティングシステムに依存しています。
The return values cap-1, cap-2, and so on, are strings specifying names of capabilities. If the capability named by cap-1 was successfully disabled, the corresponding success-1 is supplied as Boolean truth; otherwise it is the empty token list.
リターンは上限-1を評価して、上限-2などは能力の名前を指定するストリングです。 首尾よく上限-1つ指定された能力を無効にしたなら、ブール真実として対応する成功-1を供給します。 さもなければ、それは空のトークンリストです。
Greenberg & Keene [Page 27] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[27ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
Although the user can specify only one capability to disable, it is conceivable that the result of disabling that particular capability is the disabling of other, related capabilities. That is why the command response can contain information on more than one capability.
ユーザは無効にする1つの能力だけを指定できますが、それが特定の能力であると無効にするという結果が他の、そして、関連する能力を無効にすることであることは想像できます。 それはコマンド応答が1つ以上の能力の情報を含むことができる理由です。
8.13 ENABLE-CAPABILITIES Command
8.13 能力を可能にしているコマンド
Command: (ENABLE-CAPABILITIES tid capability password)}
コマンド: (ENABLE-CAPABILITIES tid能力パスワード)}
Response: (ENABLE-CAPABILITIES tid cap-1 success-1
cap-2 success-2 cap-3 success-3 ...)
応答: (ENABLE-CAPABILITIES tid上限-1成功-1上限-2成功-2上限-3成功-3)
ENABLE-CAPABILITIES causes an access capability to be enabled on the server machine. The password argument is optional, and should be included only if it is needed to enable this particular capability. Both password and capability are strings. The meaning of the capability is dependent on the operating system.
ENABLE-CAPABILITIESはサーバマシンで可能にされるべきアクセス能力を引き起こします。 パスワード議論は、任意であり、それがこの特定の能力を可能にするのに必要である場合にだけ、含まれるべきです。 パスワードと能力の両方がストリングです。 能力の意味はオペレーティングシステムに依存しています。
The return values cap-1, cap-2 and so on, are strings specifying names of capabilities. If the capability named by cap-1 was successfully enabled, the corresponding success-1 is supplied as Boolean truth; otherwise it is the empty token list.
リターン値上限-1(上限-2など)は、能力の名前を指定するストリングです。 首尾よく上限-1つ指定された能力を可能にしたなら、ブール真実として対応する成功-1を供給します。 さもなければ、それは空のトークンリストです。
Although the user can specify only one capability to enable, it is conceivable that the result of enabling that particular capability is the enabling of other, related capabilities. That is why the command response can contain information on more than one capability.
ユーザは可能にする1つの能力だけを指定できますが、その特定の能力を可能にするという結果が他の、そして、関連する能力を可能にすることであることは想像できます。 それはコマンド応答が1つ以上の能力の情報を含むことができる理由です。
8.14 EXPUNGE Command
8.14 梢消コマンド
Command: (EXPUNGE tid directory-pathname)
コマンド: (EXPUNGE tidディレクトリパス名)
Response: (EXPUNGE tid server-storage-units-freed)
応答: (解放されたEXPUNGE tidサーバストレージユニット)
EXPUNGE causes the directory specified by pathname to be expunged. Expunging means that any files that have been soft deleted are to be permanently removed.
EXPUNGEはパス名によって指定されたディレクトリを梢消させます。 梢消は、どんな削除されていた状態で柔らかいファイルも永久に取り除かれることであることを意味します。
For file systems that do not support soft deletion, the command is to be ignored; a success command response is sent, but no action is performed on the file system. In this case, the number-of-server- storage-units-freed return value should be omitted.
コマンドは柔らかい削除をサポートしないファイルシステムにおいて無視されることです。 成功コマンド応答を送りますが、ファイルシステムに動作を全く実行しません。 この場合数、-ユニットが解放したサーバストレージリターンでは、値は省略されるべきです。
directory-pathname is a required string argument in the directory pathname format; it must refer to a directory on the server file system, and not to a file. See the section "Syntax of File and Directory Pathname Arguments", section 7.4.
ディレクトリパス名はディレクトリパス名形式において必要なストリング議論です。 それはファイルではなく、サーバファイルシステムの上のディレクトリを参照しなければなりません。 「ファイルとディレクトリパス名議論の構文」というセクション、セクション7.4を見てください。
Greenberg & Keene [Page 28] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[28ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
The return value server-storage-units-freed is an integer specifying how many records, blocks, or whatever unit is used to measure file storage on the server host system, were recovered. This return value should be omitted if the server does not know how many storage units were freed.
解放されたリターン値のサーバストレージ単位がいくつが記録するかを指定する整数である、ブロック、またはサーバー・ホストシステムの上のファイル記憶装置を測定するのに使用されるどんなユニットも回収されました。 サーバが、いくつの記憶装置が解放されたかを知らないなら、このリターン値は省略されるべきです。
The protocol does not define whether directory-pathname is really a pathname as directory or a wildcard pathname of files to be expunged. The protocol does not define whether or not wildcards are permitted, or required to be supported, in the directory portion of the pathname (representing an implicit request to expunge many directories).
プロトコルは、梢消されるためにディレクトリパス名が本当にディレクトリかファイルのワイルドカードパス名としてパス名であるかどうかを定義しません。 プロトコルは、ワイルドカードがサポートされるのに許可されているか、または必要であるかどうかを定義しません、パス名のディレクトリ部分で(多くのディレクトリを梢消するという暗黙の要求を表して)。
8.15 FILEPOS Command
8.15FILEPOSが命令します。
Command: (FILEPOS tid handle position resync-uid)
コマンド: (FILEPOS tidハンドル位置resync-uid)
Response: (FILEPOS tid)
応答: (FILEPOS tid)
FILEPOS sets the file access pointer to a given position, relative to the beginning of the file. FILEPOS is used to indicate the position of the next byte of data to be transferred.
FILEPOSはファイルの始まりに比例して与えられた位置にファイルアクセス・ポインタを設定します。 FILEPOSは、データの次のバイトが移される立場を示すのに使用されます。
The handle indicates the file to be affected. handle must be a data channel handle for a data stream opening, or a direct file identifier for a direct access opening. Both handle and position are required arguments.
ハンドルは、影響を受けるようにファイルを示します。ハンドルは、データ・ストリーム始まりへのデータ・チャンネルハンドル、または直接アクセス始まりのための直接編成ファイル識別子でなければなりません。 ハンドルと位置の両方が必要な議論です。
position is an integer indicating to which point in the file the file access pointer is to be reset. position is either a byte number according to the current byte size being used, or characters for character openings. Position zero is the beginning of the file. If this is a character opening, position is measured in server units, not in NFILE character set units.
位置はファイルアクセス・ポインタがファイルのどのポイントにリセットされることになっているかを示す整数です。位置は、使用される現在のバイトサイズに従ったバイト番号、またはキャラクタ始まりへのキャラクタです。 位置ゼロはファイルの始まりです。 これがキャラクタ始まりであるなら、位置はNFILE文字集合ユニットで測定されるのではなく、サーバユニットで測定されます。
If the FILEPOS command is given on an input data channel (that is, a data channel currently sending data from server to user), the affected data channel must be resynchronized after the FILEPOS is accomplished, in order to identify the start of the new data. The resync-uid is a unique identifier associated with the resynchronization of the data channel; it is unique with respect to this dialogue. resync-uid must be supplied if handle is an input handle, but it is not supplied otherwise. For more information on the resynchronization procedure: See the section "NFILE Data Connection Resynchronization", section 9.2.
入力データ・チャンネル(すなわち、現在サーバからユーザにデータを送るデータ・チャンネル)でFILEPOSコマンドを与えるなら、FILEPOSが優れた後に影響を受けるデータ・チャンネルを再連動させなければなりません、新しいデータの始まりを特定するために。 resync-uidはデータ・チャンネルの再同期に関連しているユニークな識別子です。 それはこの対話に関してユニークです。ハンドルが入力ハンドルであるならresync-uidを供給しなければなりませんが、別の方法でそれは供給しません。 再同期手順に関する詳しい情報のために: セクション「NFILEデータ接続Resynchronization」、セクション9.2を見てください。
In the output case, the user must somehow indicate to the server, on the output data channel, when there is no more data. The user side sends the keyword token EOF to do so. Upon receiving that control
ユーザは、出力データ・チャンネルの上では、出力場合にはそれ以上のデータが全くいつにないかをサーバにどうにか示さなければなりません。 ユーザ側は、そうするためにキーワードトークンEOFを送ります。 そのコントロールを受けることに関して
Greenberg & Keene [Page 29] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[29ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
token, the server is required to position the file pointer according to the position given. When the new file position is established, the server resumes accepting data at the new file position.
トークン、サーバが、与えられた位置に応じてファイル・ポインタを置くのに必要です。 新しいファイルの位置が設置されるとき、サーバは、新しいファイルの位置でデータを受け入れるのを再開します。
In most cases, using the direct access mode of transfer is more convenient and efficient than repeated use of FILEPOS with a data stream opening.
多くの場合、転送の直接アクセスモードを使用するのは、FILEPOSのデータ・ストリームが開いている繰り返された使用より便利であって、効率的です。
There are problems inherent in trying to set a file position of a character-oriented file on a foreign host, if one machine is a Symbolics computer and the other is not. For example, character set translation must take place. See the section "NFILE Character Set", section 6. Because of these difficulties, FILEPOS might not be supported in the future on character files. FILEPOS is not problematic for binary files.
異種宿主のキャラクタ指向のファイルのファイルの位置を設定しようとするのが固有である問題があります、1台のマシンがSymbolicsコンピュータであり、もう片方がコンピュータでないなら。 例えば、文字集合翻訳は行われなければなりません。 「NFILE文字コード」というセクション、セクション6を見てください。 これらの困難のために、FILEPOSは将来、キャラクタファイルの上でサポートされないかもしれません。 バイナリーファイルには、FILEPOSは問題が多くはありません。
8.15.1 Implementation Hint for FILEPOS Command
8.15.1 FILEPOSコマンドのための実装ヒント
The server processing of this command (by the control connection handler) must not attempt to wait for the resynchronization procedure to complete. It is possible that the user could abort between sending the FILEPOS command and reading for the mark and resynchronization identifier. That scenario could leave the sender of the resynchronization identifier, on the server side, blocked for output indefinitely.
このコマンド(コントロール接続操作者による)のサーバ処理は、完了する再同期手順を待つのを試みてはいけません。 FILEPOSコマンドを送って、マークと再同期識別子をめざして勉強するときユーザが中止になることができたのは、可能です。 そのシナリオは出力のために無期限に妨げられたサーバ側の上の再同期識別子の送付者を置き去りにするかもしれません。
Only two commands received on the control connection can break the data channel out of the blocked state described above: CLOSE with abort-p supplied as Boolean truth, and RESYNCHRONIZE-DATA-CHANNEL. Therefore, the control connection must not wait for the data channel to finish performing the resynchronization procedure. This wait should instead be performed by the process managing the data channel.
コントロール接続のときに受け取られた2つのコマンドだけが以下の上で説明された妨げられた状態からデータ・チャンネルを壊すことができます。 ブール真実として供給されたアボートpがあるCLOSE、およびRESYNCHRONIZE-DATA-CHANNEL。 したがって、コントロール接続は、データ・チャンネルが、再同期手順を実行し終えるのを待ってはいけません。 この待ちは代わりにデータ・チャンネルを管理するプロセスによって実行されるべきです。
8.16 FINISH Command
8.16 終えコマンド
Command: (FINISH tid handle)
コマンド: (FINISH tidハンドル)
Response: (FINISH tid truename binary-p other-properties)
応答: (FINISH tid truenameの2進のp他の特性)
FINISH closes a file and reopens it immediately with the file position pointer saved, thus leaving it open for further I/O. If possible, the implementation should do the closing and opening in an indivisible operation, such that no other process can get access to the file.
FINISHはファイルを閉じて、すぐファイル位置の指針が保存されている状態で、それを再開させます、その結果、それをさらなる入出力において開いた状態でおきます。 できれば、実装は分割できない操作で閉鎖と始まりをするべきです、他のどんなプロセスもファイルに近づく手段を得ることができないように。
Greenberg & Keene [Page 30] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[30ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
The arguments, results, and their meaning are identical to those of the CLOSE command. See the section "CLOSE Command", section 8.3. FINISH requires a handle, which has the same meaning as the handle of the CLOSE command.
議論、結果、およびそれらの意味はCLOSEコマンドのものと同じです。 「閉鎖コマンド」というセクション、セクション8.3を見てください。 FINISHはハンドルを必要とします。(それは、CLOSEコマンドのハンドルと同じ意味を持っています)。
In the output case, for both direct mode and data stream mode of openings, the server writes out all buffers and sets the byte count of the file. The user sends the keyword token EOF on the data channel, to indicate that the end of data has been reached. The server leaves the file in such a state that if the system or server crashes anytime after the FINISH command has completed, it would later appear as though the file had been closed by this command. However, the file is not left in a closed state now; it is left open for further I/O operations. FINISH is a reliability feature.
出力場合では、サーバは、ダイレクトモードと始まりのデータ・ストリームモードの両方のために、すべてのバッファを書き上げて、ファイルのバイト・カウントを設定します。 ユーザは、データの端に達したのを示すためにデータ・チャンネルでキーワードトークンEOFを送ります。 サーバはシステムかサーバがコマンドが完成したFINISHの後にいつでもダウンするなら、後でまるでファイルがこのコマンドで閉じられたかのように見えるくらいの状態でファイルを出ます。 しかしながら、ファイルは今、閉じている状態に残されません。 それはさらなる入出力操作において開くままにされます。 FINISHは信頼性の機能です。
FINISH is somewhat pointless in the input case, but valid. The native Symbolics file system (LMFS) implements FINISH on an output file by an internal operation that effectively goes through the work of closing but leaves the file open for appending.
FINISHは入力場合でいくらか無意味ですが、有効です。 固有のSymbolicsファイルシステム(LMFS)は出力ファイルで事実上閉鎖の仕事に直面していますが、追加において開いた状態でファイルを出る内部の操作でFINISHを実装します。
ERRORS ON FINISH
終わりにおける誤り
After writing every last bit sent by the user to disk, and before closing the file, the server checks the data channel specified by handle to see if an asynchronous error is outstanding on that channel. That is, the server must determine whether it has sent an asynchronous error to the user, to which the user has not yet responded with a CONTINUE command. If so, the server is unable to finish the file, and it must send a command error response response, indicating that an error is pending on the channel. The appropriate three-letter error code is EPC. See the section "NFILE Errors and Notifications", section 10.
ディスクと、ファイルを閉じるユーザによって送られた最後のあらゆるビット前に書いた後に、サーバはハンドルによって指定された、非同期な誤りがそのチャンネルで傑出しているかどうかわかったデータ・チャンネルをチェックします。 すなわち、サーバは、それが非同期な誤りをユーザに送ったかどうか決定しなければなりません。(ユーザはCONTINUEコマンドでまだそのユーザに応じていません)。 そうだとすれば、サーバはファイルを完成させることができません、そして、コマンド誤り応答応答を送らなければなりません、誤りがチャンネルに未定であることを示して。 適切な3文字のエラーコードはEPCです。 「NFILE誤りと通知」というセクション、セクション10を見てください。
8.17 HOME-DIRECTORY Command
8.17 ホームディレクトリコマンド
Command: (HOME-DIRECTORY tid user)
コマンド: (ホームディレクトリtidユーザ)
Response: (HOME-DIRECTORY tid directory-pathname)
応答: (ホームディレクトリtidディレクトリパス名)
HOME-DIRECTORY returns the full pathname of the home directory on the server machine for the given user.
ホームディレクトリは与えられたユーザへのサーバマシンの上のホームディレクトリの完全なパス名を返します。
user is a string that should be recognizable as a user's login name on the server operating system. directory-pathname is a string in the directory pathname format. See the section "Syntax of File and Directory Pathname Arguments", section 7.4.
ユーザはユーザのログイン名としてサーバオペレーティングシステムで認識可能であるべきストリングです。ディレクトリパス名はディレクトリパス名形式のストリングです。 「ファイルとディレクトリパス名議論の構文」というセクション、セクション7.4を見てください。
Greenberg & Keene [Page 31] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[31ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
8.18 LOGIN Command
8.18 ログイン命令
Command: (LOGIN tid user password FILE-SYSTEM USER-VERSION)
コマンド: (LOGIN tidユーザパスワードFILE-SYSTEM USER-バージョン)
Response: (LOGIN tid keyword/value-pairs)
応答: (組をLOGIN tidキーワード/評価します)です。
LOGIN logs the given user in to the server machine, using the password if necessary. Both user and password are string arguments; user is required, password is optional. An omitted password is valid if the host allows the specified user to log in without a password. Depending on the operating system and server, it might be necessary to log in to run a program (in this case the NFILE server program) on the host. LOGIN establishes a user identity that is used by the operating system to establish the file author and determine file access rights during the current session.
必要なら、パスワードを使用して、LOGINはサーバマシンに与えられたユーザにログインします。 ユーザとパスワードの両方がストリング議論です。 ユーザが必要であり、パスワードは任意です。 ホストがパスワードなしで指定されたユーザをログインさせるなら、省略されたパスワードは有効です。 オペレーティングシステムとサーバによって、プログラム(この場合NFILEサーバプログラム)をホストに動かすためにログインするのが必要であるかもしれません。 LOGINはファイルの作者を設立して、現在のセッションの間、ファイルアクセス権を決定するのにオペレーティングシステムで使用されるユーザアイデンティティを確立します。
The server has the option to reject with an error any command except LOGIN if a successful LOGIN command has not been performed. This is recommended. Many operating systems perform the login function in a different process and/or environment than user programs. The portion of the NFILE server running in the special login environment could conceivably be capable only of processing the LOGIN command; this is the reason for having the LOGIN command in NFILE.
サーバには、うまくいっているLOGINコマンドが実行されていないなら、誤りでLOGIN以外のどんなコマンドも拒絶するオプションがあります。 これはお勧めです。 多くのオペレーティングシステムがユーザ・プログラムより異なったプロセス、そして/または、環境におけるログイン機能を実行します。特別なログイン環境へ駆け込むNFILEサーバの部分は多分単にLOGINコマンドを処理できるかもしれません。 これはNFILEにLOGINコマンドを持つ理由です。
FILE-SYSTEM and USER-VERSION are optional keyword/value pairs. The FILE-SYSTEM keyword/value pair selects the identity of the file system to which all following commands in this session are to be directed. This argument has meaning only if the server host machine has multiple file systems, and the targeted file system is other than the default file system that a user would get by initiating a dialogue with that host. The FILE-SYSTEM argument is an arbitrary token list. If the server does not recognize it, the server gives an appropriate command error response.
FILE-SYSTEMとUSER-バージョンは任意のキーワード/値の組です。 FILE-SYSTEMキーワード/価値の組は向けられるこのセッションにおけるすべての次のコマンドがことであるファイルシステムのアイデンティティを選択します。 この議論には、サーバホスト・マシンに複数のファイルシステムがある場合にだけ、意味があります、そして、そのホストとの対話を開始するユーザが通り抜けるデフォルトファイルシステムを除いて、狙っているファイルシステムがあります。 FILE-SYSTEM議論は任意のトークンリストです。 サーバがそれを認識しないなら、サーバは適切なコマンド誤り応答を与えます。
Currently, the only use of FILE-SYSTEM is for Symbolics servers to select one of the front-end processor hosts instead of the LMFS, which is the default. In this case, the first element in the token list is the keyword FEP, and the second element in the token list is an integer, indicating the desired FEP disk unit number. If the server discovers there is no such file system, the server gives a command error response including the three-letter code NFS, meaning "no file system". See the section "NFILE Errors and Notifications", section 10.
現在、FILE-SYSTEMの唯一の使用はSymbolicsサーバがLMFSの代わりにフロントエンドプロセッサホストのひとりを選択することです。LMFSはデフォルトです。 この場合、トークンリストにおける最初の要素はキーワードFEPです、そして、トークンリストにおける2番目の要素は整数です、必要なFEPディスクユニット番号を示して。 サーバが、どんなそのようなファイルシステムもないと発見するなら、サーバは3文字のコードNFSを含むコマンド誤り応答を与えます、「ファイルシステムがありません」を意味して。 「NFILE誤りと通知」というセクション、セクション10を見てください。
Greenberg & Keene [Page 32] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[32ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
The user tells the server what version of NFILE it is running by including the optional USER-VERSION keyword/value pair. The value associated with USER-VERSION can be a string, an integer, or a token list. This document describes NFILE user version 2 and server version 2.
ユーザは、それが任意のUSER-バージョンキーワード/価値の組を含んでいることによってNFILEのどんなバージョンを実行しているかをサーバに言います。 USER-バージョンに関連している値は、ストリング、整数、またはトークンリストであるかもしれません。 このドキュメントはNFILEユーザバージョン2とサーババージョン2について説明します。
Upon receiving the representation of the user version, the server can either adjust certain parameters to handle this particular version, or simply ignore the user version altogether. Currently, the only released versions of NFILE are user version 2 and server version 2.
ユーザバージョンの表現を受け取ると、サーバは、この特定のバージョンを扱うようにあるパラメタを調整するか、または単にユーザバージョンを全体で無視できます。 現在、NFILEの唯一のリリースされたバージョンが、ユーザバージョン2とサーババージョン2です。
LOGIN RETURN VALUES: keyword/value-pairs
ログインリターン値: 組をキーワード/評価します。
The keyword/value-pairs is a token list composed of keywords followed by their values. The server includes any or all of the following keywords and their values; they are all optional. The following keywords are recognized:
組をキーワード/評価するのは、それらの値があとに続いたキーワードで構成されたトークンリストです。 サーバは以下のキーワードとそれらの値のいずれかすべてを含んでいます。 それらはすべて任意です。 以下のキーワードは認識されます:
NAME
名前
The value associated with NAME is a string specifying the user identity, in the server host's terms.
NAMEに関連している値はサーバー・ホストの用語でユーザアイデンティティを指定するストリングです。
PERSONAL-NAME
個人名
The value associated with PERSONAL-NAME is a string representing the user's personal name, last name first. For example: "McGillicuddy, Aloysius X.".
パーソナル-NAMEに関連している値は最初にユーザの個人名、姓を表すストリングです。 例えば: 「McGillicuddy、Aloysius X.。」
HOMEDIR-PATHNAME
HOMEDIR-パス名
The value associated with HOMEDIR-PATHNAME is a string in the pathname as directory format, indicating the home directory of the user. See the section "Syntax of File and Directory Pathname Arguments", section 7.4.
HOMEDIR-PATHNAMEに関連している値はディレクトリ形式としてのパス名のストリングです、ユーザのホームディレクトリを示して。 「ファイルとディレクトリパス名議論の構文」というセクション、セクション7.4を見てください。
GROUP-AFFILIATION
グループ提携
The value associated with GROUP-AFFILIATION is a string specifying the group to which the user belongs, when this concept is appropriate.
GROUP-AFFILIATIONに関連している値はユーザが属するグループを指定するストリングです、この概念が適切であるときに。
SERVER-VERSION
サーババージョン
The value associated with SERVER-VERSION can be a string, an integer, or a token list. The value is a representation of the version of the server is running. Upon receiving the server version, the user can: adjust certain parameters to handle this particular version; accept
SERVER-バージョンに関連している値は、ストリング、整数、またはトークンリストであるかもしれません。 値はサーバのバージョンの表現が稼働しているということです。 サーババージョンを受けると、ユーザはそうすることができます: あるパラメタを調整して、この特定のバージョンを扱ってください。 受け入れてください。
Greenberg & Keene [Page 33] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[33ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
the version; or close the connection. Currently, the only released versions of NFILE are user version 2 and server version 2.
バージョン。 または、接続を終えてください。 現在、NFILEの唯一のリリースされたバージョンが、ユーザバージョン2とサーババージョン2です。
PROPERTY-INDEX-TABLE
特性割り出しテーブル
The value associated with PROPERTY-INDEX-TABLE is a token list of keywords. This return value enables the server to inform the user which file properties are meaningful on its file system. The keywords in PROPERTY-INDEX-TABLE can be used by the DIRECTORY command (a user request for information on file properties of a specified directory or directories). The server can specify a certain property by giving an integer that is the index of that file property into the PROPERTY-INDEX-TABLE. This reduces the volume of data sent during directory listings. The first element in PROPERTY-INDEX-TABLE is indexed by the number 0. See the section "DIRECTORY Command", section 8.11.
PROPERTY-INDEX-TABLEに関連している値はキーワードのトークンリストです。 このリターン値は、サーバが、どのファイルの特性がファイルシステムの上で重要であるかをユーザに知らせるのを可能にします。 ディレクトリコマンド(指定されたディレクトリかディレクトリのファイル所有地の情報に関するユーザ要求)でPROPERTY-INDEX-TABLEのキーワードを使用できます。 サーバは、そのファイルの特性のインデックスである整数をPROPERTY-INDEX-TABLEに与えることによって、ある特性を指定できます。 これはディレクトリリストの間に送られたデータ量を減少させます。 PROPERTY-INDEX-TABLEにおける最初の要素はNo.0によって索引をつけられます。 「ディレクトリコマンド」というセクション、セクション8.11を見てください。
8.19 MULTIPLE-FILE-PLISTS Command
8.19 複数のファイルPLISTSコマンド
Command: (MULTIPLE-FILE-PLISTS tid input-handle paths
characters properties)
コマンド: (MULTIPLE-FILE-PLISTS tid入力ハンドル経路キャラクタの特性)
Response: (MULTIPLE-FILE-PLISTS tid)
応答: (MULTIPLE-FILE-PLISTS tid)
MULTIPLE-FILE-PLISTS returns file property information of one or more files. The server sends the information in a data structure (the format is described later in this section) on the given input-handle. paths is an embedded token list composed of the pathnames in which the user is interested. Each pathname in this list is a string in the full pathname syntax of the server host. Unlike for the DIRECTORY command, wildcards are not allowed in these pathnames. See the section "Syntax of File and Directory Pathname Arguments", section 7.4.
MULTIPLE-FILE-PLISTSは1個以上のファイルのファイル特性の情報を返します。 サーバはデータ構造(形式は後でこのセクションで説明される)における情報を与えられた入力ハンドルに送ります。経路はユーザが興味を持っているパス名で構成された埋め込まれたトークンリストです。 サーバー・ホストの完全なパス名構文でこのリストの各パス名はストリングです。 ディレクトリコマンドなどと異なって、ワイルドカードはこれらのパス名で許容されていません。 「ファイルとディレクトリパス名議論の構文」というセクション、セクション7.4を見てください。
characters is either Boolean truth (indicating that each file is a character file), the empty token list (each file is a binary file), or the keyword DEFAULT. DEFAULT indicates that the server itself is to figure out whether a file is a character or binary file. For more information on the meaning of the DEFAULT keyword: See the section "OPEN Command", section 8.20. The value of characters can influence some servers' idea of a file's length.
キャラクタは、ブール真実(各ファイルがキャラクタファイルであることを示す)、空のトークンリスト(各ファイルはバイナリーファイルである)かキーワードDEFAULTのどちらかです。 DEFAULTは、サーバ自体がファイルがキャラクタかそれともバイナリーファイルであるかを理解することであることを示します。 DEFAULTキーワードの意味に関する詳しい情報のために: 「開いているコマンド」というセクション、セクション8.20を見てください。 キャラクタの値はファイルの長さに関するいくつかのサーバの考えに影響を及ぼすことができます。
properties is a token list of keywords indicating which properties the user wants returned. The server is always free to return more properties than those requested in the properties argument. If properties is supplied as the empty token list, the server should transmit all known properties on the files.
特性はユーザが欲しいどの資産が戻ったかを示すキーワードのトークンリストです。 サーバはいつも無料で特性の議論で要求されたものより多くの資産を返すことができます。 空のトークンリストとして資産を供給するなら、サーバはファイルの上ですべての知られている特性を伝えるべきです。
Greenberg & Keene [Page 34] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[34ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
The server transmits as much of the requested information as possible on the given input-handle. The information is contained in a top- level token list of elements. Each element corresponds with a supplied pathname; the order of the original pathlist must be retained in the returned token list. An element is an empty token list if the corresponding file or any of its containing directories does not exist. The elements that correspond to successfully located files are lists composed of truename followed by any properties. properties are keyword/value pairs. truename is a string in the full pathname syntax of the server host.
サーバは与えられた入力ハンドルに関するできるだけ多くの求められた情報を伝えます。 情報は要素の先端の平らなトークンリストに含まれています。 各要素は供給されたパス名に対応しています。 返されたトークンリストでオリジナルのpathlistの注文を保有しなければなりません。 対応するファイルかディレクトリを含むいずれも存在していないなら、要素は空のトークンリストです。 首尾よく見つけられたファイルに対応する要素はどんな特性も支えたtruenameで構成されたリストです。特性はキーワード/値の組です。サーバー・ホストの完全なパス名構文でtruenameはストリングです。
The following example shows TOP-LEVEL-LIST-BEGIN and TOP-LEVEL-LIST- END as parentheses, and LIST-BEGIN and LIST-END with square brackets.
以下の例は、括弧としてTOP-LEVEL-LIST-BEGINとTOP-LEVEL-LIST- ENDを見せていて、角括弧でLIST-BEGINとLIST-ENDを見せます。
For example, the user supplied a pathlist argument resembling:
例えば、ユーザは以下に類似しているpathlist議論を供給しました。
[file1 file2 file3]
[file1 file2 file3]
The server could not locate file1 or file3, but did locate file2, and found the length and author of file2. The top-level token list transmitted by the server is:
サーバは、file2の場所を見つけた以外に、file1かfile3の場所を見つけることができないで、file2の長さと作者を見つけました。 サーバによって伝えられたトップレベルトークンリストは以下の通りです。
( [] [ truename-of-file2 LENGTH 381 AUTHOR williams ] [] )
( [][file2 LENGTHのtruename381AUTHOR williams][] )
For further detail on how file properties and values are expressed: See the section "Format of NFILE File Property/Value Pairs", section 7.5.
ファイルの特性と値がどう示されるかに関する詳細のために: 「NFILEファイル特性/価値のペアの形式」というセクション、セクション7.5を見てください。
8.20 OPEN Command
8.20 開いているコマンド
Command: (OPEN tid handle pathname direction binary-p
TEMPORARY RAW SUPER-IMAGE DELETED PRESERVE-DATES
SUBMIT DIRECT-FILE-ID ESTIMATED-LENGTH BYTE-SIZE
IF-EXISTS IF-DOES-NOT-EXIST)
コマンド: (オープンtidハンドルパス名方向2進のp TEMPORARY RAW SUPER-IMAGE DELETED PRESERVE-DATES SUBMIT DIRECT-FILE ID ESTIMATED-LENGTH BYTE-SIZE IF EXISTS IF DOES NOT EXIST)
Response: (OPEN tid truename binary-p other-properties)
応答: (オープンのtid truenameの2進のp他の特性)
OPEN opens a file for reading, writing, or direct access at the server host. That means, in general, asking the host file system to access the file and obtaining a file number, pointer, or other quantity for subsequent rapid access to the file; this is called an "opening". See the section "NFILE File Opening Modes", section 5.
オープンはサーバー・ホストで読書、書くこと、または直接アクセスのためのファイルを開きます。 それは、一般に、ファイルにアクセスするようにホストファイルシステムに頼んで、ファイル番号、指針、または他の量をファイルへのその後の急速なアクセスに得ることを意味します。 これは「始まり」と呼ばれます。 「NFILEファイル・オープニングモード」というセクション、セクション5を見てください。
The OPEN command has the most complicated syntax of any NFILE command. The OPEN command has required arguments, an optional argument, and many optional keyword/value pairs. For details on the syntax of each of these parts of the OPEN command: See the section "Conventions Used in This Document", section 7.
オープン命令には、どんなNFILEコマンドの最も複雑な構文もあります。 オープン命令は議論、任意の議論、および多くの任意のキーワード/値の組を必要としました。 それぞれのオープンのこれらの地域の構文に関する詳細に関しては、命令してください: 「本書では使用されるコンベンション」というセクション、セクション7を見てください。
Greenberg & Keene [Page 35] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[35ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
The following arguments are required: pathname, direction, and binary-p. handle is an optional argument, which must either be supplied or explicitly omitted by means of substituting in its place the empty token list.
以下の議論が必要です: パス名、方向、および2進のp.ハンドルは任意の議論です。(供給しなければならないか、または場所で空のトークンリストを代入することによって明らかにその議論を省略しなければなりません)。
The OPEN command has many optional keyword/value pairs, which encode conceptual arguments to the server file system for the OPEN operation. A detailed description of all the supported OPEN optional keywords is given below.
オープン命令には、多くの任意のキーワード/値の組があります。(組はオープン操作のサーバファイルシステムに概念的な議論をコード化します)。 すべてのサポートしているオープン任意のキーワードの詳述を以下に与えます。
The OPEN return values reflect information about the file opened, when the opening is successful. In the case of a probe-type opening, this information is returned when the given file (or link, or directory) exists and is accessible, even though the file (or link, or directory) is not actually opened. For detail on the OPEN return values: See the section "NFILE OPEN Response Return Values", section 8.20.2.
オープンリターン値は始まりがうまくいっているとき開かれたファイルの情報を反映します。 徹底的調査タイプ始まりの場合では、与えられたファイル(または、リンク、またはディレクトリ)がいつ存在していて、アクセス可能であるかというこの情報を返します、ファイル(または、リンク、またはディレクトリ)は実際に開かれませんが。 オープンに関する詳細に関しては、値を返してください: 「NFILE OPEN応答リターン値」というセクション、セクション8.20.2を見てください。
THE pathname OPEN ARGUMENT
パス名OPEN ARGUMENT
The pathname is a required argument specifying the file to be opened. pathname is a string in the full pathname syntax of the server host. See the section "Syntax of File and Directory Pathname Arguments", section 7.4.
パス名は開かれるためにファイルを指定する必要な議論です。サーバー・ホストの完全なパス名構文でパス名はストリングです。 「ファイルとディレクトリパス名議論の構文」というセクション、セクション7.4を見てください。
For some purposes (for example, when the OPEN argument direction is supplied as PROBE-DIRECTORY), only the directory specified by this pathname is utilized. See the section "NFILE OPEN Optional Keyword/Value Pairs", section 8.20.1.
いくつかの目的(例えばPROBE-ディレクトリとしてオープン議論方向を供給するとき)のために、このパス名によって指定されたディレクトリだけが利用されています。 「NFILE OPENの任意のキーワード/価値のペア」というセクション、セクション8.20.1を見てください。
THE handle OPEN ARGUMENT
ハンドルOPEN ARGUMENT
The handle argument of the OPEN command specifies a data channel to be used for the transfer. Subsequent commands in this session use the same handle to specify this opening. It is the user side's responsibility to ensure that handle refers to an existing and free data channel that does not require resynchronization before use. A handle must be supplied, unless a probe-type opening is desired (that is, the direction is supplied as PROBE, PROBE-DIRECTORY, or PROBE- LINK) or a direct access opening is being requested (that is, a DIRECT-FILE-ID is supplied). In those cases, the empty token list is supplied for handle.
オープン命令のハンドル議論は、転送に使用されるためにデータ・チャンネルを指定します。 このセッションにおけるその後のコマンドは、この始まりを指定するのに同じハンドルを使用します。 使用の前に再同期を必要としないのは、ハンドルが存在と無料のデータ・チャンネルに言及するのを保証するユーザ側の責任です。 ハンドルを供給しなければなりません、徹底的調査タイプ始まりが望まれているか(PROBE、PROBE-ディレクトリ、またはPROBE- LINKとしてすなわち、方向を供給します)、または直接アクセス始まりが要求されていない場合(すなわち、DIRECT-FILE-IDを供給します)。 それらの場合では、空のトークンリストをハンドルに提供します。
THE direction OPEN ARGUMENT
方向OPEN ARGUMENT
The direction argument must be supplied as one of these keywords: INPUT, OUTPUT, IO, PROBE, PROBE-DIRECTORY, and PROBE-LINK. The meanings of the direction keywords are as follows:
これらのキーワードの1つとして方向議論を供給しなければなりません: 入力、出力、イーオー、徹底的調査、徹底的調査ディレクトリ、および徹底的調査リンク。 方向キーワードの意味は以下の通りです:
Greenberg & Keene [Page 36] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[36ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
INPUT
入力
Specifies that the file is to be opened for input server-to-user
transfer). To request a direct access opening, supply a value for
DIRECT-FILE-ID. If no DIRECT-FILE-ID is supplied, the opening is a
data stream opening.
指定、ファイルは入力サーバからユーザへの転送のために開かれることです) 直接アクセス始まりを要求するには、DIRECT-FILE-IDに値を供給してください。 DIRECT-FILE-IDを全く供給しないなら、始まりはデータ・ストリーム始まりです。
OUTPUT
出力
Specifies that the file is to be opened for output user-to-server
transfer). To request a direct access opening, supply a value for
DIRECT-FILE-ID. If no DIRECT-FILE-ID is supplied, the opening is a
data stream opening.
指定、ファイルは出力ユーザからサーバへの転送のために開かれることです) 直接アクセス始まりを要求するには、DIRECT-FILE-IDに値を供給してください。 DIRECT-FILE-IDを全く供給しないなら、始まりはデータ・ストリーム始まりです。
IO
イーオー
Specifies that interspersed input and output will be performed on
the file. This is only meaningful in direct access mode. A
DIRECT-FILE-ID must also be supplied. See the section "NFILE OPEN
Optional Keyword/Value Pairs", section 8.20.1.
点在している入出力がファイルに実行されると指定します。 これは直接アクセスモードだけで重要です。 また、DIRECT-FILE-IDを供給しなければなりません。 「NFILE OPENの任意のキーワード/価値のペア」というセクション、セクション8.20.1を見てください。
If direction is supplied as PROBE, PROBE-LINK, or PROBE-DIRECTORY, the opening is said to be a probe-type opening. The DIRECT-FILE-ID option is meaningless and an error for probe-type openings. The file handle must be supplied as an empty token list for probe-type openings.
PROBE、PROBE-LINK、またはPROBE-ディレクトリとして方向を供給するなら、徹底的調査タイプ始まりであると始まりを言います。 DIRECT-FILE-IDオプションは、無意味であって、徹底的調査タイプ始まりのための誤りです。 徹底的調査タイプ始まりのための空のトークンリストとしてファイルハンドルを供給しなければなりません。
PROBE
徹底的調査
Specifies that the file is not to be opened at all, but simply
checked for existence. If the file does not exist or is not
accessible, the error indications and actions are identical to
those that would be given for an INPUT opening. If the file does
exist, the successful command response contains the same
information as it would have if the file had been opened for
INPUT. If it is a link, the link is followed to its target.
ファイルが全く開かれるのではなく、存在がないかどうか絶対にチェックされることであると指定します。 ファイルが存在していないか、またはアクセス可能でないなら、誤り指摘と動きはINPUT始まりに与えられているものと同じです。 ファイルが存在しているなら、ファイルがINPUTのために開かれたなら、うまくいっているコマンド応答は含んでいるように同じ情報を含んでいます。 それがリンクであるなら、リンクは目標に続かれています。
PROBE-LINK
徹底的調査リンク
Like PROBE, with one difference. PROBE-LINK specifies that if the
pathname is found to refer to a link, that link is not to be
followed, and information about the link itself is to be returned.
1つの違いがあるPROBEのように。 PROBE-LINKは、リンク自体の情報がパス名がリンクについて言及するのがわかっているなら、そのリンクに続いてはいけなくて、返されることであると指定します。
Greenberg & Keene [Page 37] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[37ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
PROBE-DIRECTORY
徹底的調査ディレクトリ
PROBE-DIRECTORY requests information about the directory
designated by the pathname argument. In the PROBE-DIRECTORY case,
the pathname argument refers to the directory on which information
is requested. In all other cases, the pathname refers to a file
to be opened. If pathname contains a file name and file type,
these parts of the pathname are ignored for PROBE-DIRECTORY
openings as long as they are syntactically valid.
PROBE-ディレクトリはパス名議論で指定されたディレクトリの情報を要求します。 PROBE-ディレクトリ場合では、パス名議論は情報が要求されているディレクトリを参照します。 他のすべての場合では、パス名は、開かれるためにファイルを示します。 パス名がファイル名とファイルの種類を含んでいるなら、それらがシンタクス上有効である限り、パス名のこれらの部分はPROBE-ディレクトリ始まりに無視されます。
THE binary-p OPEN ARGUMENT
2進のp OPEN ARGUMENT
The value of binary-p affects the mode in which the server opens the file, as well as informing it whether or not character set translation must be performed.
2進のpの値はサーバが文字集合翻訳を実行しなければならないかどうかをそれに知らせることと同様にファイルを開くモードに影響します。
If binary-p is supplied as the empty token list, the opening is said to be a character opening. The server performs character set translation between its native character set and the NFILE character set. The data is transferred over the data connection one character per eight-bit byte. See the section "NFILE Character Set", section 6.
空のトークンリストとして2進のpを供給するなら、キャラクタ始まりであると始まりを言います。 サーバはネイティブの文字集合とNFILE文字集合の間の文字集合翻訳を実行します。 8ビットのバイトあたりのデータ接続1キャラクタの上にデータを移します。 「NFILE文字コード」というセクション、セクション6を見てください。
If binary-p is supplied as Boolean truth, the opening is said to be a binary opening. The user side supplies the byte size via the BYTE- SIZE option; if not supplied, the default byte size is 16 bits. If byte size is less than 9, the file data is transferred byte by byte. If the byte size is 9 or greater, the server transfers each byte of the file as two eight-bit bytes, low-order first.
ブール真実として2進のpを供給するなら、2進の始まりであると始まりを言います。 ユーザ側はBYTE- SIZEオプションでバイトサイズを供給します。 供給されないなら、デフォルトバイトサイズは16ビットです。 バイトサイズが9未満であるなら、ファイルデータはバイトですごとにわたる。 バイトサイズが9以上であるなら、サーバは最初に、8ビットの2バイトとしてのファイルの各バイト、下位を移します。
binary-p can also be supplied as the keyword DEFAULT. DEFAULT specifies that the server itself is to determine whether to transfer binary or character data. DEFAULT is meaningful only for input openings; it is an error for OUTPUT, IO, or probe-type openings. For file systems that maintain the innate binary or character nature of a file, the server simply asks the file system which case is in force for the file specified by pathname.
また、キーワードDEFAULTとして2進のpを供給できます。 DEFAULTは、サーバ自体がバイナリーかキャラクタデータを移すかどうか決定することであると指定します。 入力始まりだけに、DEFAULTは重要です。 それはOUTPUT、IO、または徹底的調査タイプ始まりのための誤りです。 ファイルの生まれながらのバイナリーかキャラクタ本質を維持するファイルシステムのために、サーバは、パス名によって指定されたファイルに、どのケースが有効であるかを単にファイルシステムに尋ねます。
When binary-p is supplied as DEFAULT, on file systems that do not maintain thisinformation, the server is required to perform a heuristic check for Symbolicsobject fileson the first two 16-bit bytes of the file. If the file isdetermined to be aSymbolics object file, the server performs a BINARY openingwith BYTE-SIZE of16; otherwise, it performs a CHARACTER opening.
DEFAULTとしてthisinformationを維持しないファイルシステムの上で2進のpを供給するとき、Symbolicsobject filesonのためにファイルについて発見的なチェックを16ビットの最初の2バイト実行するためにサーバを必要とします。 ファイルがaSymbolicsオブジェクトファイルになるようにisdeterminedされたなら、サーバはBINARY openingwith BYTE-SIZE of16を実行します。 さもなければ、それはキャラクター始まりを実行します。
Greenberg & Keene [Page 38] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[38ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
The details of the check are as follows: if the first 16-bit byte is the octal number170023 and the second 16-bit byte is any number between 0 and 77 octal(inclusive), the file is recognized as a Symbolics object file. In any othercase, it is not.
チェックの詳細は以下の通りです: 最初の16ビットのバイトが8進number170023であり、2番目の16ビットのバイトが0と77 8進(包括的な)の間のあらゆる数であるなら、ファイルはSymbolicsオブジェクトファイルとして認識されます。 どんなothercaseでも、それはそうではありません。
8.20.1 NFILE OPEN Optional Keyword/Value Pairs
8.20.1 NFILEの開いている任意のキーワード/価値のペア
The OPEN command has many optional keyword/value pairs that encode conceptual arguments to the file system for the OPEN operation.
オープン命令には、オープン操作のファイルシステムに概念的な議論をコード化する多くの任意のキーワード/値の組があります。
The following options are used often:
以下のオプションはしばしば使用されます:
BYTE-SIZE
バイト-サイズ
Must be followed by an integer between 1 and 16, inclusive, or the
empty token list. BYTE-SIZE is meaningful only for binary
openings. BYTE-SIZE can be ignored for probe-type openings. It
can be omitted entirely for character openings, but if supplied,
must be followed by the empty token list. If binary-p is supplied
as DEFAULT, BYTE-SIZE can be omitted entirely, or followed by the
empty token list.
包括的な1〜16の整数か空のトークンリストがあとに続かなければなりません。 2進の始まりだけに、BYTE-SIZEは重要です。 徹底的調査タイプ始まりにBYTE-SIZEを無視できます。 それを完全に、キャラクタ始まりにもかかわらず、供給するなら省略できて、空のトークンリストはあとに続かなければなりません。 DEFAULTとして2進のpを供給するなら、空のトークンリストは、BYTE-SIZEの完全に省略されるか、またはあとに続くことができます。
If a binary opening is requested and BYTE-SIZE is not supplied,
the assumed value is 16 for output openings. For input binary
openings, the default is the host file system's stored conception
of the file's byte size (for those hosts that natively support
byte size). For file systems that do not natively support
natively byte size, the default byte-size on binary input is 16.
2進の始まりが要求されていて、BYTE-SIZEが供給されないなら、前提値は出力始まりへの16です。 入力バイナリーのために、始まりであり、デフォルトはファイルのバイトサイズに関するホストファイルシステムの保存された概念(バイトがサイズであるとネイティブにサポートするそれらのホストのために)です。 ネイティブバイトがサイズであるとネイティブにサポートしないファイルシステムのために、2進の入力のデフォルトバイト-サイズは16です。
For file systems that maintain the innate byte-size of each file,
the server should supply this number to the appropriate operating
system interface that performs the semantics of opening the file.
For other operating systems, a file written with a given byte size
must produce the same bytes in the same order when read with that
byte size. In this case, the server or host operating system can
choose any packing scheme that complies with this rule.
それぞれのファイルの生まれながらのバイト-サイズを維持するファイルシステムのために、サーバはファイルを開く意味論を実行する適切なオペレーティングシステムインタフェースにこの数を供給するべきです。 他のオペレーティングシステムのために、そのバイトサイズで読まれると、与えられたバイトサイズで書かれたファイルは同次における同じバイトを生産しなければなりません。 この場合、サーバかホスト・オペレーティング・システムがこの規則に従うどんなパッキング体系も選ぶことができます。
Operating systems that do not support byte size must ensure that
binary files written from user ends of the current protocol can be
read back correctly. However, the server can choose packing
schemes that allow all bits of the server host's word to be
accessed and concur with other packing schemes used by native host
software.
バイトがサイズであるとサポートしないオペレーティングシステムは、正しく現在のプロトコルのユーザ終わりから書かれたバイナリーファイルを読み返すことができるのを確実にしなければなりません。 しかしながら、サーバは、サーバー・ホストのすべてのビットの言葉がアクセスされるのを許容する体系を梱包するのを選んで、他のパッキング体系が固有のホストソフトウェアによって使用されている状態で、同意できます。
For example, Multics supports 36 bit words and 9 bit bytes. A
packing scheme appropriate for a Multics NFILE server is:
例えば、Multicsは、36ビットの単語と9ビットがバイトであるとサポートします。 Multics NFILEサーバに、適切なパッキング体系は以下の通りです。
Greenberg & Keene [Page 39] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[39ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
Byte Size Packing Scheme
バイトサイズパッキング体系
7, 8, or 9 bits four per 36-bit word
10, 11, or 12 bits three per 36-bit word
13, 14, 15, or 16 bits two per 36-bit word
8ビットか7ビットか36ビットあたり4が36ビットの単語あたり3に13ビットか14ビットか15ビットか16ビットに36ビットの単語あたり2に10ビットか11ビットか12ビット言い表す9ビット
In the first packing scheme in the table, native Multics
character-oriented software can access each logical byte
sequentially. In the last packing scheme, each Symbolics byte is
in a halfword, easily accessible and visible in an octal
representation. To achieve maximum data transfer rate and access
all bits of a Multics word, a byte size of 12 must be specified.
テーブルにおける最初のパッキング体系では、固有のMulticsキャラクタ指向のソフトウェアはそれぞれの論理的なバイトに連続してアクセスできます。 最後のパッキング体系では、それぞれのSymbolicsバイトは、8進表現でhalfwordにあって、容易にアクセスしやすくて、目に見えます。 最大のデータ転送速度を達成して、Multics単語、1バイトのすべてのビットにアクセスするために、12のサイズを指定しなければなりません。
DELETED
削除されます。
If supplied as Boolean truth, DELETED specifies that deleted"
files are to be treated as though they were not "deleted".
DELETED is meaningful only for operating systems that support
"soft deletion" and subsequent "undeletion" of files. Other
operating systems must ignore this option. Normally, deleted
files are not visible to the OPEN operation; this option makes
them visible.
「ブール真実として供給するなら、削除されて、DELETEDはそれを指定する」ファイルがまるでそれらが「削除されないかの」ように扱われることです。 ファイルの「柔らかい削除」とその後の"非削除"をサポートするオペレーティングシステムだけに、DELETEDは重要です。 他のオペレーティングシステムはこのオプションを無視しなければなりません。 通常、削除されたファイルはオープン操作に目に見えません。 このオプションで、それらは目に見えるようになります。
DELETED can also be followed by the empty token list, which has
the same effect as omitting the DELETED keyword/value pair
entirely. For output openings, DELETED is meaningless and an
error if supplied.
また、空のトークンリストはDELETEDのあとに続くことができます。(それは、DELETEDキーワード/価値の組を完全に省略するのと同じ効果を持っています)。 出力始まりに関しては、供給するなら、DELETEDは無意味であって、誤りです。
DIRECT-FILE-ID
ダイレクトFILE ID
If supplied, the DIRECT-FILE-ID indicates that the opening is to
be a direct access mode opening. If not supplied, the opening is
a data stream opening. The value of DIRECT-FILE-ID is a string
generated by the user, that has not been used as a DIRECT-FILE-ID
in this dialogue, and does not designate any data channel. The
DIRECT-FILE-ID is a unique identifier for the direct access
opening. It is used for all operations that identify an opening
rather than a data channel. The DIRECT-FILE-ID is used to
identify a direct access opening, just as a file handle is used to
identify a data stream opening. The PROPERTIES, CLOSE, and RENAME
commands use the DIRECT-FILE-ID in this way. There are only two
NFILE commands applicable to direct access openings (ABORT and
CONTINUE) that do not use the DIRECT-FILE-ID, but use a data
channel handle instead.
供給するなら、DIRECT-FILE-IDは、始まりによる直接アクセスモード始まりであることになっていることを示します。 供給されないなら、始まりはデータ・ストリーム始まりです。 DIRECT-FILE-IDの値がユーザによって生成されたストリングであり、それは、DIRECT-FILE-IDとしてこの対話に使用されていなくて、また少しのデータ・チャンネルも任命しません。 DIRECT-FILE-IDは直接アクセス始まりのためのユニークな識別子です。 それはデータ・チャンネルよりむしろ始まりを特定するすべての操作に使用されます。 DIRECT-FILE-IDは、ちょうどファイルハンドルがデータ・ストリーム始まりを特定するのに使用されるように開く直接アクセスを特定するのに使用されます。 PROPERTIES、CLOSE、およびRENAMEコマンドはこのようにDIRECT-FILE-IDを使用します。 DIRECT-FILE-IDではなく、データチャンネルが代わりに扱う使用を使用するアクセス始まり(ABORTとCONTINUE)を向けるのにおいて適切な2つのNFILEコマンドしかありません。
PRESERVE-DATES
保護区日付
If supplied as Boolean truth, PRESERVE-DATES specifies that the
ブール真実として供給するなら、PRESERVE-DATESはそれを指定します。
Greenberg & Keene [Page 40] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[40ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
server is to attempt to prevent the operating system from updating
the "reference date" or date-time used" of the file. This is
meaningful only for input openings, and is an error otherwise.
「サーバはオペレーティングシステムが費やされた「参照日付」か日付-時にアップデートするのを防ぐのを試みることです。」ファイルについて。 入力始まりだけにおいて、重要です。そうでなければ、これは、誤りです。
The Symbolics operating system invokes this option for operations
such as View File in the editor, where it wishes to assert that
the user did not "read" the file, but just "looked at it".
Servers on operating systems that do not support reference dates
or users revising or suppressing update of the reference dates
must ignore this option.
SymbolicsオペレーティングシステムはエディタのView Fileなどの操作のためのこのオプションを呼び出します。そこでは、それが、ユーザがファイルを「読みませんでした」が、まさしく「それを見た」と断言したがっています。 参照日付をサポートしないオペレーティングシステムに関するサーバか参照日付のアップデートを改訂するか、または抑圧するユーザがこのオプションを無視しなければなりません。
ESTIMATED-LENGTH
およそ長さ
The value of ESTIMATED-LENGTH is an integer estimating the length
of the file to be transferred. This option is meaningful and
permitted only for output openings. ESTIMATED-LENGTH enables the
user end to suggest to the server's file system how long the file
is going to be. This can be useful for file systems that must
preallocate files or file maps or that accrue performance benefits
from knowing this information at nthe time the file is first
opened. This estimate, if supplied, is not required to be exact.
It is ignored by servers to which it is not useful or interesting.
The units of the estimate are characters for character openings,
and bytes of the agreed-upon byte size for binary openings. The
character units should be server units, if possible, but since
this is only an estimate, NFILE character units are acceptable.
See the section "NFILE Character Set", section 6.
ESTIMATED-LENGTHの値は移すためにファイルの長さを見積もっている整数です。 このオプションは、重要で出力始まりだけに受入れられます。 ESTIMATED-LENGTHは、ユーザ終わりが、ファイルがどれくらい長い間あるかをサーバのファイルシステムに示すのを可能にします。 これはファイル、ファイル地図またはそれがファイルが最初に開かれるnthe時にこの情報を知りながら性能利益を生じさせるpreallocateがそうしなければならないファイルシステムの役に立つ場合があります。 供給するなら、厳密に言えばこの見積りを必要としません。 それは役に立たないで、またおもしろくないサーバによって無視されます。 見積りのユニットは、キャラクタ始まりへのキャラクタと、2進の始まりへの同意しているバイトサイズのバイトです。 キャラクタユニットはできればサーバユニットであるべきですが、これが見積りにすぎないので、NFILEキャラクタユニットは許容できます。 「NFILE文字コード」というセクション、セクション6を見てください。
IF-EXISTS
-、存在
Meaningful only for output openings, ignored otherwise, but not
diagnosed as an error. The value of IF-EXISTS is a keyword that
specifies the action to Be taken if a file of the given name
already exists. The semantics of the values are derived from the
Common Lisp specification and repeated here for completeness. If
the file does not already exist, the IF-EXISTS option and its
value are ignored.
別の方法で無視されますが、誤りは診断されなかった出力始まりだけにおいて、重要です。 値、-、EXISTS、名のファイルが既に存在しているなら取られたBeに動作を指定するキーワードはそうです。 Common Lisp仕様から派生して完全性のためにここで繰り返された値の意味論。 ファイルが既に存在していないなら-、EXISTS、オプションとその値は無視されます。
If the user side does not give the IF-EXISTS option, The action to
be taken if a file of the given name already exists depends on
whether or not the file system supports file versions. If it
does, the default is ERROR (if an explicit version is given in the
file pathname) or NEW-VERSION (if the version in the file pathname
is the newest version). For file systems not supporting versions,
the default is SUPERSEDE. These actions are described below.
ユーザ側が与えない、-、EXISTS、オプション、当然のことの名のファイルが既に存在しているなら取られるべき動作はファイルシステムがファイルバージョンをサポートするかどうかによります。 そうするなら、デフォルトは、ERROR(ファイルパス名で明白なバージョンを与えるなら)かNEW-バージョン(ファイルパス名のバージョンが最も新しいバージョンであるなら)です。 バージョンをサポートしないファイルシステムのために、デフォルトはSUPERSEDEです。 これらの動作は以下で説明されます。
Greenberg & Keene [Page 41] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[41ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
IF-EXISTS provides the mechanism for overwriting or appending to
files. With the default setting of IF-EXISTS, new files are
created by every output opening.
-、EXISTS、ファイルへの上書きか追加にメカニズムを提供します。 既定の設定、-、EXISTS、新しいファイルはあらゆる出力始まりによって作成されます。
Operating systems supporting soft deletion can take different
actions if a "deleted" file already exists with the same name (and
type and version, where appropriate) as a file to be created. The
Symbolics file system (LMFS) effectively uses SUPERSEDE, even if
not asked to do so. Other servers and file systems are urged to
do similarly. Recommended action is to not allow deleted files to
prevent successful file creation (with specific version number)
even if an IF-EXISTS option weaker than SUPERSEDE, RENAME, or
RENAME-AND-DELETE is specified or implied.
「削除された」ファイルが同じ名前で既に存在しているなら柔らかい削除をサポートするオペレーティングシステムが異なった行動を取ることができる、(タイプとバージョン、どこ、適切である、)、作成されるべきファイルとして。 そうするように頼まれないでも、事実上、Symbolicsファイルシステム(LMFS)はSUPERSEDEを使用します。 他のサーバとファイルシステムが同様にするよう促されます。 お勧めの動作が削除されたファイルがうまくいっているファイル作成(特定のバージョン番号がある)を防ぐのを許容しないことである、-、EXISTS、SUPERSEDEか、RENAMEか、RENAMEとDELETEより弱いオプションは、指定されるか、または含意されます。
Here are the possible values and their meanings:
ここに、可能な値とそれらの意味があります:
ERROR
誤り
Reports an error.
誤りを報告します。
NEW-VERSION
新しいバージョン
Creates a new file with the same file name but with a larger
version number. This is the default when the version component
of the filename is newest. File systems without version
numbers can implement this by effectively treating it as
SUPERSEDE.
同じファイル名にもかかわらず、より大きいバージョン番号で新しいファイルを作成します。 ファイル名のバージョン成分が最も新しいときに、これはデフォルトです。 バージョン番号のないファイルシステムは、事実上、SUPERSEDEとしてそれを扱うことによって、これを実装することができます。
RENAME
改名します。
Renames the existing file to some other name and then creates a
new file with the specified name. On most file systems, this
renaming happens at the time of a successful close.
ある他の名前に既存ファイルを改名して、次に、指定された名前で新しいファイルを作成します。 ほとんどのファイルシステムの上では、この改名はうまくいっている閉鎖時点で、起こります。
RENAME-AND-DELETE
改名して、削除します。
Renames the existing file to some other name and then deletes
it (but does not expunge it, on those systems that distinguish
deletion from expunging). Then it creates a new file with the
specified name. On most file systems, this renaming happens at
the time of a successful close.
ある他の名前に既存ファイルを改名して、次に、それ(しかし、梢消と削除を区別するそれらのシステムの上でそれを梢消しない)を削除します。 そして、それは指定された名前で新しいファイルを作成します。 ほとんどのファイルシステムの上では、この改名はうまくいっている閉鎖時点で、起こります。
OVERWRITE
重ね書き
Output operations on the opening destructively modify the
existing file. New data replaces old data at the beginning of
the file; however, the file is not truncated to length zero
upon opening.
始まりにおける出力操作は既存ファイルを破壊的に変更します。 新しいデータはファイルの始めに古いデータを置き換えます。 しかしながら、ファイルは始まりの長さゼロに先端を切られません。
Greenberg & Keene [Page 42] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[42ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
TRUNCATE
先端を切ります。
Output operations on the opening destructively modify the
existing file. The file pointer is initially positioned at the
beginning of the file; at that time, TRUNCATE truncates the
file to length zero and frees disk storage occupied by it.
始まりにおける出力操作は既存ファイルを破壊的に変更します。 ファイル・ポインタはファイルの始めに初めは、置かれます。 その時、TRUNCATEは長さゼロにファイルに先端を切らせて、それによって占領されたディスクストレージを解放します。
APPEND
追加します。
Output operations on the opening destructively modify the
existing file. New data is placed at the current end of the
file.
始まりにおける出力操作は既存ファイルを破壊的に変更します。 新しいデータはファイルの現在の端に置かれます。
SUPERSEDE
取って代わります。
Supersedes the existing file. This means that the old file is
removed or deleted and expunged. The new file takes its place.
If possible, the file system does not destroy the old file
until the new file is closed, against the possibility that the
file will be close-aborted. This differs from NEW-VERSION in
that SUPERSEDE creates a new file with the same name as the old
one, rather than a file name with a higher version number.
既存ファイルに取って代わります。 これは、食えない奴を取り除くか、削除して、または梢消することを意味します。 新しいファイルは代わりをします。 できれば、新しいファイルが閉じられるまで、ファイルシステムは食えない奴を破壊しません、ファイルが近くで中止になられる可能性に対して。 これはSUPERSEDEが、より大きいバージョン番号があるファイル名よりむしろ古い方と同じ名前で新しいファイルを作成するという点においてNEW-バージョンと異なっています。
There are currently no standards on what a server can do if it
cannot implement some of these actions.
これらの動作のいくつかを実装することができないなら、現在、サーバができることが規格が全くありません。
IF-DOES-NOT-EXIST
NOTは存在しています。
Meaningful for input openings, never meaningful for probe-type
openings, and sometimes meaningful for output openings. IF-DOES-
NOT-EXIST takes a value token, which specifies the action to be
taken if the file does not already exist. Like IF-EXISTS, it is a
derivative of Common Lisp. The default is as follows: If this is
a probe-type opening or read opening, or if the IF-EXISTS option
is specified as OVERWRITE, TRUNCATE, or APPEND, the default is
ERROR. Otherwise, the default is CREATE.
入力始まりに重要で、徹底的調査タイプ始まりには決して重要でなくて、出力始まりに時々重要です。 -どれかDOES EXISTが値のトークン(ファイルが既に存在していないなら、取るために動作を指定する)を取らないなら。 -、EXISTS、それはCommon Lispの派生物です。 デフォルトは以下の通りです: または、徹底的調査タイプはこれであるなら開くか、または始まりを読まれる、-、EXISTS、オプションが、OVERWRITE、TRUNCATE、またはAPPEND、デフォルトがERRORであるので、指定されます。 さもなければ、デフォルトはCREATEです。
These are the values for IF-DOES-NOT-EXIST:
これらが値である、EXISTではなく、DOESであるなら:
ERROR
誤り
Reports an error.
誤りを報告します。
CREATE
作成します。
Creates an empty file with the specified name and then proceeds
as if it already existed.
指定された名前で空のファイルを作成して、次に、まるで既に存在しているかのように続きます。
Greenberg & Keene [Page 43] RFC 1037 NFILE - A File Access Protocol December 1987
グリーンバーグとキーン[43ページ]RFC1037NFILE--ファイルアクセスプロトコル1987年12月
The following optional keyword/value pairs are rarely used, if ever:
かつてなら、以下の任意のキーワード/値の組はめったに使用されません:
RAW
生
If supplied as Boolean truth, RAW specifies that character set
translation is not to be performed, but that characters are to be
transferred intact, without inspection. This option is meaningful
only for character openings; it is an error otherwise. It is also
an error to supply RAW as Boolean truth for probe-type openings.
RAW can also be followed by the empty token list, which has the
same effect as if the RAW keyword/value pair were omitted
entirely. See the section "RAW Translation Mode", Appendix B.
ブール真実として供給するなら、RAWは、文字集合翻訳が実行されないことですが、キャラクタが完全な状態で移されることになっていると指定します、点検なしで。 キャラクタ始まりだけに、このオプションは重要です。 そうでなければ、それは誤りです。 また、それは徹底的調査タイプ始まりへのブール真実としてRAWを供給する誤りです。 また、空のトークンリストはRAWのあとに続くことができます。(まるでRAWキーワード/価値の組が完全に省略されるかのようにそれは、同じ効果を持っています)。 Appendix B、「生の翻訳モード」というセクションを見てください。
SUPER-IMAGE
超イメージ
If supplied as Boolean truth, SUPER-IMAGE specifies that Rubout
quoting is not to be performed. This operation is meaningful only
for character openings; it is an error otherwise. It is also an
error for probe-type openings. SUPER-IMAGE can also be followed
by the empty token list, which has the same effect as if the
SUPER-IMAGE keyword/value pair were omitted entirely.
ブール真実として供給するなら、SUPER-IMAGEは、Rubout引用が実行されないことであると指定します。 キャラクタ始まりだけに、この操作は重要です。 そうでなければ、それは誤りです。 また、それは徹底的調査タイプ始まりのための誤りです。 また、空のトークンリストはSUPER-IMAGEのあとに続くことができます。(まるでSUPER-IMAGEキーワード/価値の組が完全に省略されるかのようにそれは、同じ効果を持っています)。
一覧
スポンサーリンク
