As per Relevance of the word oriented, we have this rfc below:
RFC 775 Directory oriented FTP commands Page 1
DIRECTORY ORIENTED FTP
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
manipulate as ordinary files, we have found it convenient
expand the FTP servers on these machines to include
which deal with the creation of directories. Since there
other hosts on the ARPA net which have tree-like directories
including Tops-20 and Multics, we have tried to make
commands as general as possible
We have added four commands to our server
XMKD
Make a directory with the name "child".
XRMD
Remove the directory with the name "child".
Print the current working directory
Change to the parent of the current
directory
The "child" argument should be created (removed) as
subdirectory of the current working directory, unless the "child
string contains sufficient information to specify otherwise
the server, e.g., "child" is an absolute pathname (in Multics
Unix), or child is something like "" to Tops-20.
RFC 775 Directory oriented FTP commands Page 2
REPLY
The XCUP command is a special case of XCWD, and is included
simplify the implementation of programs for
directory trees between operating systems having
syntaxes for naming the parent directory. Therefore we
that the reply codes for XCUP be identical to the reply codes
XCWD
Similarly, we recommend that the reply codes for XRMD
identical to the reply codes for its file analogue, DELE
The reply codes for XMKD, however, are a bit more complicated.
freshly created directory will probably be the object of a
XCWD command. Unfortunately, the argument to XMKD may not
be a suitable argument for XCWD. This is the case, for example
when a Tops-20 subdirectory is created by giving just
subdirectory name. That is, with a Tops-20 server FTP,
command
XMKD
XCWD
will fail. The new directory may only be referred to by
"absolute" name; e.g., if the XMKD command above were
while connected to the directory , the
subdirectory could only be referred to by the
.
Even on Unix and Multics, however, the argument given to XMKD
not be suitable. If it is a "relative" pathname (that is,
pathname which is interpreted relative to the current directory),
the user would need to be in the same current directory in
to reach the subdirectory. Depending on the application,
may be inconvenient. It is not very robust in any case
To solve these problems, upon successful completion of an
command, the server should return a line of the form
257"<directory-name>"
That is, the server will tell the user what string to use
referring to the created directory. The directory name
contain any character; embedded double-quotes should be
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,
creates a subdirectory, named child
XCWD /usr/
200 directory changed to /usr/
XMKD
257 "/usr/dm/child" directory
An example with an embedded double quote
XMKD foo"
257 "/usr/dm/foo""bar" directory
XCWD /usr/dm/foo"
200 directory changed to /usr/dm/foo"
We feel that the prior existence of a subdirectory with the
name should be interpreted as an error, and have implemented
server to give an "access denied" error reply in that case
CWD /usr/
200 directory changed to /usr/
XMKD
521-"/usr/dm/child" directory already exists
521 taking no action
We recommend that failure replies for XMKD be analogous to
file creating cousin, STOR. Also, we recommend that an "
denied" return be given if a file name with the same name as
subdirectory will conflict with the creation of the
(this is a problem on Unix, but shouldn't be one on Tops-20).
Essentially because the XPWD command returns the same type
information as the successful XMKD command, we have
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 257
is the only new code. Reply codes shown within parentheses
for the "new" ftp protocol, most recently documented in RFC 765.
RFC 775 Directory oriented FTP commands Page 4
The invented code for the RFC 765 Protocol is 251.
Command
reply code
XMKD create
257 (251) "pathname"
521 (450) "pathname" already
506 (502) action not
521 (450) access
550 (501) bad pathname syntax or
425 (451) random file system
XCUP change directory
superior of current
200 (200) working directory
506 (502) action not
507 (551) no superior
521 (450) access
425 (451) random file system
XRMD remove
224 (250) deleted
506 (502) action not
521 (450) access
550 (501) bad pathname syntax or
425 (451) random file system
XPWD print current
257 (251) "pathname
425 (451) random file system
506 (502) action not
RFC 775 Directory oriented FTP commands Page 5
Because these commands will be most useful in
subtrees from one machine to another, we must stress the
that the argument to XMKD is to be interpreted as a sub-
of the current working directory, unless it contains
information for the destination host to tell otherwise.
hypothetical example of its use in the Tops-20 world
XCWD
200 Working directory
XMKD
257 "" directory
XCWD
431 No such
XCWD
200 Working directory
XCWD
200 Working directory changed to
XMKD
257 "" directory
XCWD
Note that the first example results in a subdirectory of
connected directory. In contrast, the argument in the
example contains enough information for Tops-20 to tell that
directory is a top-level directory. Note also
in the first example the user "violated" the protocol
attempting to access the freshly created directory with a
other than the one returned by Tops-20. Problems could
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
this: except where to do so would violate a host's
for denoting relative versus absolute pathnames, the host
treat the operands of the XMKD and XRMD commands
subdirectories. The 257 reply to the XMKD command must
contain the absolute pathname of the created directory
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, 14 July 1975
One More Try on the FTP (RFC 691), Harvey, B., NIC 32700, 28
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
1977
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
