Directory oriented FTP commands
Directory commands for FTP on systems with hierarchical filesystems
Mankins, D., Franklin, D., and A.D. Owen, "Directory oriented FTP commands", RFC 775, DOI 10.17487/RFC0775, December 1980, <https://www.rfc-editor.org/info/rfc775>.
@misc{rfc775,
series = {Request for Comments},
number = 775,
howpublished = {RFC 775},
publisher = {RFC Editor},
doi = {10.17487/RFC0775},
url = {https://www.rfc-editor.org/info/rfc775},
author = {D. Mankins and D. Franklin and A.D. Owen},
title = {{Directory oriented FTP commands}},
pagetotal = 6,
year = 1980,
month = dec,
} RFC text
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.
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
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.
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
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
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
AI ELI5
On this page
§1FTP Commands for Directories
This RFC defines four new commands to extend the File Transfer Protocol (FTP) on systems that organize files in tree-like directory structures. The commands were developed at BBN for its Unix servers but work equally on Tops-20 and Multics, and solve a key gap: the original FTP protocol had no standard way to create directories, remove them, or navigate between levels of the directory tree.
FTP could transfer files but could not create the folders they live in. These four commands fill that gap.
§2The Four Commands
The RFC introduces four commands prefixed with X to mark them as experimental. XMKD (make directory) creates a subdirectory with a given name in the current working directory, or at a specified absolute path. XRMD (remove directory) deletes a subdirectory. XPWD (print working directory) returns the full pathname of the current working directory. XCUP (change to parent) moves up one level to the parent directory.
An important detail: when XMKD succeeds, the server responds with the absolute pathname of the newly created directory. This ensures clients can reliably refer to the directory, because on some systems like Tops-20 a relative directory name given to XMKD must be accessed by its full absolute path.
XMKD makes a folder, XRMD deletes one, XPWD tells you where you are, and XCUP takes you up one level. When you create a folder, FTP tells you its full address so you can find it later.
§3Reply Codes
Each command has standardized response codes. XMKD returns code 257 on success with the directory name, 521 if the directory already exists, and codes for access denied, bad syntax or file system errors. XCUP uses the same success code (200) as the change-directory command it resembles, with codes for access denied, no parent directory, or system errors. XRMD uses codes similar to the file-delete command, with 224 on success. XPWD returns 257 with the pathname on success, or error codes for system problems or unimplemented commands.
The RFC emphasizes that reply code 257 is the only entirely new code introduced; others map to existing FTP codes or are taken from concurrent RFC 765.
Each command gets a number back: 257 means success for XMKD and XPWD, 200 for XCUP, and different numbers for errors like 'folder already exists' or 'you cannot do this'.