RFC 775          Directory oriented FTP commands        Page 1


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

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

Print the current working directory.

Change to the parent of 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 "<abso.lute.path>" to Tops-20.


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

Similarly, we recommend that the reply codes for XRMD be identical to the reply codes for its file analogue, DELE.

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


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

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 an XMKD command, the server should return a line of the form:


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 child:

XCWD /usr/dm
200 directory changed to /usr/dm
XMKD child
257 "/usr/dm/child" directory created

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

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

The invented code for the RFC 765 Protocol is 251.


	      reply code      explanation

      XMKD                    create directory

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

      XCUP                    change directory to
				      superior of current one

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

      XRMD                    remove directory

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

      XPWD                    print current working

257 (251) "pathname"
425 (451) random file system error
506 (502) action not implemented


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 <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>
200 Working directory changed to <some.where>
XMKD <unambiguous>
257 "<unambiguous>" directory created
XCWD <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 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.


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

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