Документ взят из кэша поисковой машины. Адрес оригинального документа : http://mirror.msu.net/pub/rfc-editor/rfc-ed-all/pdfrfc/rfc775.txt.pdf Дата изменения: Wed Mar 27 23:50:05 2002 Дата индексирования: Tue Oct 2 16:34:48 2012 Кодировка:

RFC 775

Directory oriented FTP commands

Page 1

DIRECTORY ORIENTED FTP COMMANDS David Mankins (dm@bbn-unix) Dan Franklin (dan@bbn-unix) A. D. Owen (ADOwen@bbnd)

As a part of the Remote Site Maintenance (RSM) project for ARPA, BBN has installed and maintains the software of several DEC PDP11s running the Unix operating system. Since Unix has a treelike 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. We have added four commands to our server:

XMKD child Make a directory with the name "child". XRMD child Remove the directory with the name "child". XPWD Print the current working directory. XCUP Change to the parent of directory. the current working

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 "" to Tops-20.


RFC 775

Directory oriented FTP commands

Page 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. Similarly, we recommend that the reply codes for XRMD identical to the reply codes for its file analogue, DELE. be

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 MYDIR XCWD MYDIR will fail. The new directory "absolute" name; e.g., if while connected to the subdirectory could only . may only be referred to by its the XMKD command above were issued directory , the new be referred to by the name

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. To solve these problems, upon successful completion of command, the server should return a line of the form: 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 an XMKD


RFC 775

Directory oriented FTP commands

Page 3

by double-quotes (the "quote-doubling" convention). For example, a user connects to the creates a subdirectory, named child: XCWD 200 XMKD 257 directory /usr/dm, and

/usr/dm directory changed to /usr/dm child "/usr/dm/child" directory created

An example with an embedded double quote: XMKD 257 XCWD 200 foo"bar "/usr/dm/foo""bar" directory created /usr/dm/foo"bar directory changed to /usr/dm/foo"bar

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. 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). 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. We present here a summary of the proposed reply codes for experimental commands. The codes given outside parentheses consistent with RFC 691; i.e., are for the old protocol, updated by the suggestions in that RFC. The server and programs at BBN-Unix currently implement these codes. Reply is the only new code. Reply codes shown within parentheses for the "new" ftp protocol, most recently documented in RFC the are as user 257 are 765.


RFC 775

Directory oriented FTP commands

Page 4

The invented code for the RFC 765 Protocol is 251. Command: reply code explanation

XMKD 257 521 506 521 550 425 XCUP (251) (450) (502) (450) (501) (451)

create directory "pathname" created "pathname" already exists action not implemented access denied bad pathname syntax or ambiguous random file system error change directory to superior of current one 200 506 507 521 425 (200) (502) (551) (450) (451) working directory changed action not implemented no superior directory access denied random file system error remove directory 224 506 521 550 425 (250) (502) (450) (501) (451) deleted ok action not implemented access denied bad pathname syntax or ambiguous random file system error print current working directory 257 (251) "pathname" 425 (451) random file system error 506 (502) action not implemented

XRMD

XPWD


RFC 775

Directory oriented FTP commands

Page 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: XCWD 200 Working directory changed XMKD overrainbow 257 "" directory created XCWD overrainbow 431 No such directory XCWD 200 Working directory changed XCWD 200 XMKD 257 XCWD Working directory changed to "" directory created

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 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 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.

References File Transfer Protocol (RFC 765), Postel, J., June 1980


RFC 775

Directory oriented FTP commands

Page 6

CWD Command of FTP (RFC 697), Lieb, J., NIC 32963, One More Try on the FTP (RFC 691), Harvey, B., NIC 1975 Revised FTP Reply Codes (RFC 640), Postel, J., Pogran, NIC 30843, 5 June 1974 File Transfer Protocol (RFC 542), Neigus, N., NIC 1977

14 July 1975 32700, 28 May N. Neigus, K.

17759,

12 July