Connected: An Internet Encyclopedia
RFC 959 - APPENDIX II - DIRECTORY COMMANDS

Top: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 959
Prev: APPENDIX I - PAGE STRUCTURE
Next: APPENDIX III - RFCs on FTP

### APPENDIX II - DIRECTORY COMMANDS

Since UNIX has a tree-like directory structure in which directories are as easy to manipulate as ordinary files, it is useful 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-Internet which have tree-like directories (including TOPS-20 and Multics), these commands are as general as possible.

Four directory commands have been added to FTP:

MKD pathname

  Make a directory with the name "pathname".

RMD pathname

  Remove the directory with the name "pathname".

PWD

  Print the current working directory name.

CDUP

  Change to the parent of the current working directory.

The "pathname" argument should be created (removed) as a subdirectory of the current working directory, unless the "pathname" string contains sufficient information to specify otherwise to the server, e.g., "pathname" is an absolute pathname (in UNIX and Multics), or pathname is something like "<abso.lute.path>" to TOPS-20.

REPLY CODES

The CDUP command is a special case of CWD, and is included to simplify the implementation of programs for transferring directory trees between operating systems having different syntaxes for naming the parent directory. The reply codes for CDUP be identical to the reply codes of CWD.

The reply codes for RMD be identical to the reply codes for its file analogue, DELE.

The reply codes for MKD, however, are a bit more complicated. A freshly created directory will probably be the object of a future CWD command. Unfortunately, the argument to MKD may not always be a suitable argument for CWD. 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

             MKD MYDIR
             CWD MYDIR

will fail. The new directory may only be referred to by its "absolute" name; e.g., if the MKD command above were issued while connected to the directory <DFRANKLIN>, the new subdirectory could only be referred to by the name <DFRANKLIN.MYDIR>.

Even on UNIX and Multics, however, the argument given to MKD may not be suitable. If it is a "relative" pathname (i.e., 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 an MKD command, the server should return a line of the form:

             257<space>"<directory-name>"<space><commentary>

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 by double-quotes (the "quote-doubling" convention).

For example, a user connects to the directory /usr/dm, and creates a subdirectory, named pathname:

             CWD /usr/dm
             200 directory changed to /usr/dm
             MKD pathname
             257 "/usr/dm/pathname" directory created

An example with an embedded double quote:

             MKD foo"bar
             257 "/usr/dm/foo""bar" directory created
             CWD /usr/dm/foo"bar
             200 directory changed to /usr/dm/foo"bar

The prior existence of a subdirectory with the same name is an error, and the server must return an "access denied" error reply in that case.

             CWD /usr/dm
             200 directory changed to /usr/dm
             MKD pathname
             521-"/usr/dm/pathname" directory already exists;
             521 taking no action.

The failure replies for MKD are analogous to its file creating cousin, STOR. Also, an "access denied" return is 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 PWD command returns the same type of information as the successful MKD command, the successful PWD command uses the 257 reply code as well.

SUBTLETIES

Because these commands will be most useful in transferring subtrees from one machine to another, carefully observe that the argument to MKD 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:

             CWD <some.where>
             200 Working directory changed
             MKD overrainbow
             257 "<some.where.overrainbow>" directory created
             CWD overrainbow
             431 No such directory
             CWD <some.where.overrainbow>
             200 Working directory changed

             CWD <some.where>
             200 Working directory changed to <some.where>
             MKD <unambiguous>
             257 "<unambiguous>" directory created
             CWD <unambiguous>

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 RMD 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 MKD and RMD commands as subdirectories. The 257 reply to the MKD command must always contain the absolute pathname of the created directory.

Next: APPENDIX III - RFCs on FTP

Connected: An Internet Encyclopedia
RFC 959 - APPENDIX II - DIRECTORY COMMANDS