path: root/doc/rfc/rfc775.txt

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

	   XPWD
			 Print the current working directory.

	   XCUP
			 Change to the parent of  the  current  working
			 directory.



      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.







^L





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

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

      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:

	       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





^L





      RFC 775          Directory oriented FTP commands        Page 3



      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.





^L





      RFC 775          Directory oriented FTP commands        Page 4



      The invented code for the RFC 765 Protocol is 251.

      Command:

	      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
				      directory

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










^L





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



				 References

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




^L





      RFC 775          Directory oriented FTP commands        Page 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
^L