RFC775 日本語訳
0775 Directory oriented FTP commands. D. Mankins, D. Franklin, A.D.Owen. December 1980. (Format: TXT=9511 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
RFC 775 Directory oriented FTP commands Page 1
RFC775のディレクトリの指向のFTPは1ページを命令します。
DIRECTORY ORIENTED FTP COMMANDS
ディレクトリはFTPコマンドを適応させました。
David Mankins (dm@bbn-unix) Dan Franklin (dan@bbn-unix) A. D. Owen (ADOwen@bbnd)
デヴィッド・マンキンズ( dm@bbn-unix )・ダン・フランクリン( dan@bbn-unix )・A.D.オーエン( ADOwen@bbnd )
As a part of the Remote Site Maintenance (RSM) project for ARPA,
BBN has installed and maintains the software of several DEC PDP-
11s running the Unix operating system. Since Unix has a tree-
like directory structure, in which directories are as easy to
manipulate as ordinary files, we have found it convenient to
expand the FTP servers on these machines to include commands
which deal with the creation of directories. Since there are
other hosts on the ARPA net which have tree-like directories,
including Tops-20 and Multics, we have tried to make these
commands as general as possible.
ARPAのためのRemote Site Maintenance(RSM)プロジェクトの一部として、BBNは、インストールして、いくつかのDEC PDP11年代の稼働のソフトウェアがUnixオペレーティングシステムであることを支持します。 Unixにはディレクトリ構造のような木があるので、ディレクトリが普通のファイルとして操る簡単であるとしてどれであるかで、私たちは、ディレクトリの作成に対処するコマンドを含むようにFTPサーバをこれらのマシンに広げるのが便利であることがわかりました。 どれにTops-20を含む木のようなディレクトリがあるか、そして、Multics、他のホストがARPAネットにいるので、私たちはこれらのコマンドをできるだけ一般的にしようとしました。
We have added four commands to our server:
私たちは4つのコマンドをサーバに追加しました:
XMKD child Make a directory with the name "child".
「子供」という名前があるXMKD子供Make aディレクトリ。
XRMD child Remove the directory with the name "child".
XRMD子供Remove、「子供」という名前があるディレクトリ。
XPWD Print the current working directory.
XPWD Print、現在の働くディレクトリ。
XCUP Change to the parent of the current working directory.
現在の働くディレクトリの親へのXCUP Change。
The "child" argument should be created (removed) as a
subdirectory of the current working directory, unless the "child"
string contains sufficient information to specify otherwise to
the server, e.g., "child" is an absolute pathname (in Multics and
Unix), or child is something like "<abso.lute.path>" to Tops-20.
「子供」議論は現在の働くディレクトリに関するサブディレクトリとして作成されるべきです(取り外します)、「子供」ストリングが別の方法でサーバに指定する十分な情報を含んでいるか、例えば、「子供」が絶対パス名(MulticsとUnixの)であるまたは子供がTops-20への「<abso.lute.path>」に似ていない場合。
RFC 775 Directory oriented FTP commands Page 2
RFC775のディレクトリの指向のFTPは2ページを命令します。
REPLY CODES
回答コード
The XCUP command is a special case of XCWD, and is included to
simplify the implementation of programs for transferring
directory trees between operating systems having different
syntaxes for naming the parent directory. Therefore we recommend
that the reply codes for XCUP be identical to the reply codes of
XCWD.
XCUPコマンドは、XCWDの特別なケースであり、親ディレクトリを命名するための異なった構文を持っているオペレーティングシステムの間にディレクトリツリーを移すためのプログラムの実装を簡素化するために含まれています。 したがって、私たちは、XCUPのための回答コードがXCWDの回答コードと同じであることを推薦します。
Similarly, we recommend that the reply codes for XRMD be
identical to the reply codes for its file analogue, DELE.
DELE、同様に、私たちはファイルアナログに、XRMDのための回答コードが回答コードと同じであることを推薦します。
The reply codes for XMKD, however, are a bit more complicated. A
freshly created directory will probably be the object of a future
XCWD command. Unfortunately, the argument to XMKD may not always
be a suitable argument for XCWD. This is the case, for example,
when a Tops-20 subdirectory is created by giving just the
subdirectory name. That is, with a Tops-20 server FTP, the
command sequence
しかしながら、XMKDのための回答コードはもう少し複雑です。 新たに作成されたディレクトリはたぶん将来のXCWDコマンドの目的になるでしょう。 残念ながら、XMKDへの議論はいつもXCWDに、適当な議論であるかもしれないというわけではありません。 Tops-20サブディレクトリがまさしくサブディレクトリ名を与えることによって作成されるとき、例えば、これはそうです。 Tops-20サーバFTPで、それはコマンド・シーケンスです。
XMKD MYDIR XCWD MYDIR
XMKD MYDIR XCWD MYDIR
will fail. The new directory may only be referred to by its
"absolute" name; e.g., if the XMKD command above were issued
while connected to the directory <DFRANKLIN>, the new
subdirectory could only be referred to by the name
<DFRANKLIN.MYDIR>.
失敗するでしょう。 新しいディレクトリは「絶対」の名前によって参照されるだけであるかもしれません。 例えば、XMKDコマンドが上にあるなら、ディレクトリ<DFRANKLIN>に接続されている間、発行されて、>という名前<DFRANKLIN.MYDIRは新しいサブディレクトリを示すことができるだけでしょうに。
Even on Unix and Multics, however, the argument given to XMKD may
not be suitable. If it is a "relative" pathname (that is, a
pathname which is interpreted relative to the current directory),
the user would need to be in the same current directory in order
to reach the subdirectory. Depending on the application, this
may be inconvenient. It is not very robust in any case.
しかしながら、UnixとMulticsでさえ、XMKDに与えられた議論は適当でないかもしれません。 それが「相対的な」パス名(すなわち、カレントディレクトリに比例して解釈されるパス名)であるなら、ユーザは、同じカレントディレクトリの中にサブディレクトリに達するようにいる必要があるでしょう。 アプリケーションによって、これは不便であるかもしれません。 どのような場合でも、それはそれほど強健ではありません。
To solve these problems, upon successful completion of an XMKD
command, the server should return a line of the form:
これらの問題を解決するために、XMKDコマンドの無事終了のときに、サーバはフォームの系列を返すべきです:
257<space>"<directory-name>"<space><commentary>
257<スペース>、「「<宇宙><論評>」という<ディレクトリ名>。
That is, the server will tell the user what string to use when
referring to the created directory. The directory name can
contain any character; embedded double-quotes should be escaped
すなわち、サーバは、作成されたディレクトリを参照するとき、どんなストリングを使用したらよいかをユーザに言うでしょう。 ディレクトリ名はどんなキャラクタも含むことができます。 埋め込まれた二重引用符逃げられるべきです。
RFC 775 Directory oriented FTP commands Page 3
RFC775のディレクトリの指向のFTPは3ページを命令します。
by double-quotes (the "quote-doubling" convention).
二重引用符(「引用文が倍増している」コンベンション)で。
For example, a user connects to the directory /usr/dm, and
creates a subdirectory, named child:
子供は、例えば、ユーザがディレクトリ/usr/dmに接続して、サブディレクトリを作成すると命名しました:
XCWD /usr/dm 200 directory changed to /usr/dm XMKD child 257 "/usr/dm/child" directory created
257"/usr/dm/child"ディレクトリが創造した/usr/dm XMKD子供に変わるXCWD/usr/dm200ディレクトリ
An example with an embedded double quote:
埋め込まれた二重引用文がある例:
XMKD foo"bar 257 "/usr/dm/foo""bar" directory created XCWD /usr/dm/foo"bar 200 directory changed to /usr/dm/foo"bar
XMKD foo、「バー257"/usr/dm/foo"「バー」ディレクトリがXCWD/usr/dm/fooを作成した、「バー200ディレクトリは/usr/dm/foo「バー」に変化しました。
We feel that the prior existence of a subdirectory with the same
name should be interpreted as an error, and have implemented our
server to give an "access denied" error reply in that case.
私たちは、同じ名前があるサブディレクトリの先の存在が誤りとして解釈されるべきであると感じて、その場合「アクセス拒否」エラー応答を与えるためにサーバを実装しました。
CWD /usr/dm 200 directory changed to /usr/dm XMKD child 521-"/usr/dm/child" directory already exists; 521 taking no action.
/usr/dm XMKD子供521"/usr/dm/child"ディレクトリに変わるCWD/usr/dm200ディレクトリは既に存在しています。 521 行動を全く取りません。
We recommend that failure replies for XMKD be analogous to its
file creating cousin, STOR. Also, we recommend that an "access
denied" return be given if a file name with the same name as the
subdirectory will conflict with the creation of the subdirectory
(this is a problem on Unix, but shouldn't be one on Tops-20).
私たちは、XMKDのための失敗回答がいとこ、STORを作成するファイルに類似していることを勧めます。 また、私たちは、サブディレクトリと同じ名前があるファイル名がサブディレクトリの作成と衝突するなら(これは、Unixの上の問題ですが、Tops-20の1であるべきではありません)「アクセス拒否」リターンが与えられることを勧めます。
Essentially because the XPWD command returns the same type of
information as the successful XMKD command, we have implemented
the successful XPWD command to use the 257 reply code as well.
本質的にはうまくいっているXMKDが命令するようにXPWDコマンドが同じタイプの情報を返すので、私たちは、うまくいっているXPWDがまた、257回答コードを使用するコマンドであると実装しました。
We present here a summary of the proposed reply codes for the
experimental commands. The codes given outside parentheses are
consistent with RFC 691; i.e., are for the old protocol, as
updated by the suggestions in that RFC. The server and user
programs at BBN-Unix currently implement these codes. Reply 257
is the only new code. Reply codes shown within parentheses are
for the "new" ftp protocol, most recently documented in RFC 765.
私たちは実験的なコマンドのためにここに提案された回答コードの概要を提示します。 括弧の外で与えられたコードはRFC691と一致しています。 すなわち、老人のために、そのRFCでの提案でアップデートされるとしてのプロトコルはものですか? BBN-unixにおけるサーバとユーザ・プログラムは現在、これらのコードを実装します。 回答257は唯一の新法です。 ごく最近は、括弧の中に示された回答コードが「新しい」ftpプロトコルのためのものであるとRFC765に記録しました。
RFC 775 Directory oriented FTP commands Page 4
RFC775のディレクトリの指向のFTPは4ページを命令します。
The invented code for the RFC 765 Protocol is 251.
RFC765プロトコルのための発明されたコードは251です。
Command:
コマンド:
reply code explanation
回答コード説明
XMKD create directory
XMKDはディレクトリを作成します。
257 (251) "pathname" created 521 (450) "pathname" already exists 506 (502) action not implemented 521 (450) access denied 550 (501) bad pathname syntax or ambiguous 425 (451) random file system error
257(251)「パス名」作成された521(450)「パス名」が既に(501)の悪いパス名実装している521(450)アクセス拒否550構文ではなく、506(502)動作かあいまいな状態で存在している、425(451)ランダムファイルシステム誤り
XCUP change directory to
superior of current one
XCUPはディレクトリを現在のものの上司に変えます。
200 (200) working directory changed 506 (502) action not implemented 507 (551) no superior directory 521 (450) access denied 425 (451) random file system error
200 (200) 働くディレクトリ変えられた506(502)動作は、507(551)いいえが優れたディレクトリ521(450)アクセス拒否425(451)ランダムファイルシステム誤りであると実装しませんでした。
XRMD remove directory
XRMDはディレクトリを取り外します。
224 (250) deleted ok 506 (502) action not implemented 521 (450) access denied 550 (501) bad pathname syntax or ambiguous 425 (451) random file system error
224 (250)は550の(501)の悪いパス名構文かあいまいな425(451)ランダムファイルシステム・エラーが否定された521(450)アクセスであることは実装されなかった間違いない506(502)動作を削除しました。
XPWD print current working
directory
XPWDは現在の働くディレクトリを印刷します。
257 (251) "pathname" 425 (451) random file system error 506 (502) action not implemented
506(502)動作が実装しなかった257(251)「パス名」425(451)ランダムファイルシステム誤り
RFC 775 Directory oriented FTP commands Page 5
RFC775のディレクトリの指向のFTPは5ページを命令します。
SUBTLETIES
微妙さ
Because these commands will be most useful in transferring
subtrees from one machine to another, we must stress the fact
that the argument to XMKD is to be interpreted as a sub-directory
of the current working directory, unless it contains enough
information for the destination host to tell otherwise. A
hypothetical example of its use in the Tops-20 world:
1台のマシンから別のマシンまで下位木を移す際にこれらのコマンドが最も役に立つので、私たちはXMKDへの議論が現在の働くディレクトリに関するサブディレクトリとして解釈されることであるという事実を強調しなければなりません、あて先ホストが別の方法で言うことができるくらいの情報を含んでいない場合。 Tops-20世界での使用の仮定している例:
XCWD <some.where> 200 Working directory changed XMKD overrainbow 257 "<some.where.overrainbow>" directory created XCWD overrainbow 431 No such directory XCWD <some.where.overrainbow> 200 Working directory changed
XCWD<some.where>200Workingディレクトリ変えられたXMKD overrainbow257「<some.where.overrainbow>」ディレクトリがそのようなディレクトリのXCWDのXCWD overrainbow431ノー<を作成したので、some.where.overrainbow>200Workingディレクトリは変化しました。
XCWD <some.where> 200 Working directory changed to <some.where> XMKD <unambiguous> 257 "<unambiguous>" directory created XCWD <unambiguous>
<の>のXMKDの<の明白なsome.where>257「<の明白な>」ディレクトリに変わるXCWD<some.where>200WorkingディレクトリはXCWDの<の明白な>を作成しました。
Note that the first example results in a subdirectory of the
connected directory. In contrast, the argument in the second
example contains enough information for Tops-20 to tell that the
<unambiguous> directory is a top-level directory. Note also that
in the first example the user "violated" the protocol by
attempting to access the freshly created directory with a name
other than the one returned by Tops-20. Problems could have
resulted in this case had there been an <overrainbow> directory;
this is an ambiguity inherent in some Tops-20 implementations.
Similar considerations apply to the XRMD command. The point is
this: except where to do so would violate a host's conventions
for denoting relative versus absolute pathnames, the host should
treat the operands of the XMKD and XRMD commands as
subdirectories. The 257 reply to the XMKD command must always
contain the absolute pathname of the created directory.
最初の例が接続ディレクトリに関するサブディレクトリをもたらすことに注意してください。 対照的に、2番目の例における議論はTops-20が、<の明白な>ディレクトリがトップレベルディレクトリであると言うことができるくらいの情報を含んでいます。 また、最初の例では、Tops-20によって返されたもの以外の名前で新たに作成されたディレクトリにアクセスするのを試みることによってユーザがプロトコルに「違反した」と述べてください。 <「過剰-虹」の>ディレクトリがあったなら、問題はこの場合結果として生じることができたでしょうに。 これはいくつかのTops-20実装に固有のあいまいさです。 同様の問題はXRMDコマンドに適用されます。 要点はこうだ: そうするのが絶対パス名に対して親類を指示するためにホストのコンベンションに違反するところを除いて、ホストはサブディレクトリとしてXMKDとXRMDコマンドのオペランドを扱うべきです。 XMKDコマンドに関する257回答はいつも作成されたディレクトリの絶対パス名を含まなければなりません。
References
参照
File Transfer Protocol (RFC 765), Postel, J., June 1980
ファイル転送プロトコル(RFC765)、ポステル、J.、1980年6月
RFC 775 Directory oriented FTP commands Page 6
RFC775のディレクトリの指向のFTPは6ページを命令します。
CWD Command of FTP (RFC 697), Lieb, J., NIC 32963, 14 July 1975
One More Try on the FTP (RFC 691), Harvey, B., NIC 32700, 28 May
1975
Revised FTP Reply Codes (RFC 640), Postel, J., N. Neigus, K.
Pogran, NIC 30843, 5 June 1974
File Transfer Protocol (RFC 542), Neigus, N., NIC 17759, 12 July
1977
FTP(RFC697)のCWDコマンド、Lieb、J.、NIC32963、さらに1975年7月14日のものはFTP(RFC691)を試着します、ハーヴェイ、B.、NIC32700、1975年5月28日の改訂されたFTP回答コード(RFC640)、ポステル、J.、N.Neigus、K.Pogran、NIC30843、1974年6月5日のファイル転送プロトコル(RFC542)、Neigus、N.、NIC17759、1977年7月12日
一覧
スポンサーリンク
