RFC 775

DIRECTORY ORIENTED FTP COMMANDS 📁✨

RFC 775 🦋 is by David Mankins (dm@bbn-unix), Dan Franklin (dan@bbn-unix), and A. D. Owen (ADOwen@bbnd) 💖 The copy I was given doesn't list a date, category, or what it obsoletes or updates, so I'm not guessing 🙈

Okay so, as part of the Remote Site Maintenance (RSM) project for ARPA, BBN installs and maintains the software on several DEC PDP-11s running Unix 🖥️ Unix has a tree-like directory structure where directories are as easy to handle as ordinary files, so it made total sense to expand the FTP servers on these machines with commands that deal with creating directories 🌳 Other ARPAnet hosts have tree-like directories too, including Tops-20 and Multics, so we tried to keep these commands as general as possible 🫶

We 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 gets created (or removed) as a subdirectory of the current working directory, unless the "child" string has enough info to tell the server otherwise 🧚 For example, "child" could be an absolute pathname (in Multics and Unix), or it could be something like "<abso.lute.path>" for Tops-20 💅

---

REPLY CODES 🎀

The XCUP command is basically a special case of XCWD 💁‍♀️ It's included to make it easier to write programs that transfer directory trees between operating systems that have different syntaxes for naming the parent directory 🌈 So 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 are a bit more complicated, ngl 😭 A freshly created directory will probably be the target of a future XCWD command. The problem is the argument to XMKD may not always be a suitable argument for XCWD. For example, that happens when a Tops-20 subdirectory is created by giving just the subdirectory name. So with a Tops-20 server FTP, this command sequence:

XMKD MYDIR
XCWD MYDIR

will fail 💀 The new directory can only be referred to by its "absolute" name. For example, if the XMKD command above was issued while connected to the directory <DFRANKLIN>, the new subdirectory could only be referred to as <DFRANKLIN.MYDIR> 🙈

Even on Unix and Multics, the argument given to XMKD might not be suitable 🥺 If it's a "relative" pathname (a pathname interpreted relative to the current directory), the user would need to be in that same current directory to reach the subdirectory. Depending on the application, that could be inconvenient, and it's not very robust in any case 😬

So to fix all of this, after an XMKD command completes successfully, the server should return a line of this form:

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

Basically, the server tells the user exactly 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

Here's 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 a subdirectory with the same name already existing should count as an error 🚫 So our server gives 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 an "access denied" return if a file with the same name as the subdirectory would conflict with creating that subdirectory. This is a problem on Unix, but it shouldn't be one on Tops-20 🌸

Because the XPWD command returns the same type of info as a successful XMKD, we made a successful XPWD use the 257 reply code too 💖

Here's a summary of the proposed reply codes for the experimental commands 🔥 The codes outside parentheses are consistent with RFC 691, which means they're 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. The codes inside 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 🔍

Okay, this part is important bestie 👑 These commands are most useful for transferring subtrees from one machine to another, so we have to stress that the argument to XMKD is interpreted as a subdirectory of the current working directory, unless it contains enough info for the destination host to tell otherwise 🌟 Here's a hypothetical example 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>

The first example creates a subdirectory of the connected directory 📂 The argument in the second example has enough info for Tops-20 to tell that the <unambiguous> directory is a top-level directory 🧠 Also, in the first example the user "violated" the protocol by trying to access the freshly created directory with a name other than the one Tops-20 returned 😳 Problems could have happened there if an <overrainbow> directory had existed. That's an ambiguity baked into some Tops-20 implementations 🙈 Similar considerations apply to the XRMD command 💫

The point is this: except where doing 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 🫶 And 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