Rfc0959 txt

For example, the client issues a command to retrieve a file from the server via the control channel. A data connection is then established, and the file's contents transferred to the client across it. Once the transfer is complete, the data connection is closed.

Meanwhile, the control connection is maintained. Data connections may be set up in two different ways, active and passive. Note that active and passive refer to the operation of the FTP server, not the client. In passive mode, the client sends a PASV command to the server. This tells the server to listen for a connection attempt from the client, hence the server is passively waiting.

The server replies to PASV with the host and port address that the server is listening on. The client deciphers this reply and when a data connection is required, attempts to initiate the connection to the server at this address. In active mode, the server actively connects to the client.

To set up active mode, the client sends a PORT command to the server, specify the address and port number the client is listening on. When a data connection is required, the server initiates a connection to the client at this address. FTP commands sent across the control connection consist of simple text strings and follow the Telnet protocol - see RFC To transfer a file, the client sends "STOR filename". The FTP server acknowledges each command with an FTP reply, which consists of a three digit number followed by human-readable text.

The first digit indicates if the response is good, bad, or incomplete. If an error occurred, the second digit may be used to indicate what type of error occurred. Similarly, the third digit can indicate more details of the error. User system inserts the command e. For other servers this may not be necessary but the actions listed above should have no unusual effect. Every command must generate at least one reply, although there may be more than one; in the latter case, the multiple replies must be easily distinguished.

The replies show the existence of an intermediate state if all preceding commands have been successful. A failure at any point in the sequence necessitates the repetition of the entire sequence from the beginning. The details of the command-reply sequence are made explicit in a set of state diagrams below. An FTP reply consists of a three digit number transmitted as three alphanumeric characters followed by some text.

The number is intended for use by automata to determine what state to enter next; the text is intended for the human user. It is intended that the three digits contain enough encoded information that the user-process the User-PI will not need to examine the text and may either discard it or pass it on to the user, as appropriate.

In particular, the text may be server-dependent, so there are likely to be varying texts for each reply code. There will be cases however, where the text is longer than a single line. In these cases the complete text must be bracketed so the User-process knows when it may stop reading the reply i. This requires a special format on the first line to indicate that more than one line is coming, and another on the last line to designate it as the last.

At least one of these must contain the appropriate reply code to indicate the state of the transaction. To satisfy all factions, it was decided that both the first and last line codes should be the same. Thus the format for multi-line replies is that the first line will begin with the exact required reply code, followed immediately by a Hyphen, "-" also known as Minus , followed by text. If an intermediary line begins with a 3-digit number, the Server must pad the front to avoid confusion.

This scheme allows standard system routines to be used for reply information such as for the STAT reply , with "artificial" first and last lines tacked on. In rare cases where these routines are able to generate three digits and a Space at the beginning of any line, the beginning of each text line should be offset by some neutral text, like Space. This scheme assumes that multi-line replies may not be nested. The three digits of the reply each have a special significance. This is intended to allow a range of very simple to very sophisticated responses by the user-process.

The first digit denotes whether the response is good, bad or incomplete. A user-process that wants to know approximately what kind of error occurred e.

There are five values for the first digit of the reply code: 1yz Positive Preliminary reply The requested action is being initiated; expect another reply before proceeding with a new command.

The user-process sending another command before the completion reply would be in violation of protocol; but server-FTP processes should queue any commands that arrive while a preceding command is in progress.

This type of reply can be used to indicate that the command was accepted and the user-process may now pay attention to the data connections, for implementations where simultaneous monitoring is difficult. The server-FTP process may send at most, one 1yz reply per command. A new request may be initiated. The user should send another command specifying this information.

This reply is used in command sequence groups. The user should return to the beginning of the command sequence, if any. It is difficult to assign a meaning to "transient", particularly when two distinct sites Server- and User-processes have to agree on the interpretation.

A rule of thumb in determining if a reply fits into the 4yz or the 5yz Permanent Negative category is that replies are 4yz if the commands can be repeated without any change in command form or in properties of the User or Server e.

The User-process is discouraged from repeating the exact request in the same sequence. Even some "permanent" error conditions can be corrected, so the human user may want to direct his User-process to reinitiate the command sequence by direct action at some point in the future e.

The following function groupings are encoded in the second digit: x0z Syntax - These replies refer to syntax errors, syntactically correct commands that don't fit any functional category, unimplemented or superfluous commands. The third digit gives a finer gradation of meaning in each of the function categories, specified by the second digit. The list of replies below will illustrate this. The reply codes, on the other hand, must strictly follow the specifications in the last section; that is, Server implementations should not invent new codes for situations that are only slightly different from the ones described here, but rather should adapt codes already defined.

If the command is not implemented by a particular Server-FTP process because it has no relevance to that computer system, for example ALLO at a TOPS20 site, a Positive Completion reply is still desired so that the simple User-process knows it can proceed with its course of action. A reply is used in this case with, for example, the reply text: "No storage allocation necessary. A refinement of that is the reply for a command that is implemented, but that requests an unimplemented parameter.

This may include errors such as command line too long. On how to use the server or the meaning of a particular non-standard command. This reply is useful only to the human user. Logged out if appropriate. This may be a reply to any command if the service knows it must shut down.

Requested file action successful for example, file transfer or file abort. File unavailable e. Local error in processing. Page type unknown. Insufficient storage space in system. Exceeded storage allocation for current directory or dataset.

File name not allowed. The user or user protocol interpreter shall initiate the full-duplex control connection. Servers are under no obligation to provide for editing of command lines and may require that it be done in the user host. The control connection shall be closed by the server at the user's request after all transfers and replies are completed.

The server shall initiate the data connection from his own default data port L-1 using the specified user data port.

The direction of the transfer and the port used will be determined by the FTP service command. One of the servers, say A, is then sent a PASV command telling him to "listen" on his data port rather than initiate a connection when he receives a transfer service command. The user-PI may then send the corresponding service commands to A and B. Server B initiates the connection and the transfer proceeds. If the data connection is to be closed following a data transfer where closing the connection is not required to indicate the end-of-file, the server must do so immediately.

Waiting until after a new transfer command is not permitted because the user-process will have already tested the data connection to see if it needs to do a "listen"; remember that the user must "listen" on a closed data port BEFORE sending the transfer request. To prevent a race condition here, the server sends a reply after closing the data connection or if the connection is left open, a "file transfer completed" reply and the user-PI should wait for one of these replies before issuing a new transfer command.

Any time either the user or server see that the connection is being closed by the other side, it should promptly read any remaining data queued on the connection and issue the close on its own side. The command syntax is specified here. The commands begin with a command code followed by an argument field.

The command codes are four or fewer alphabetic characters. Upper and lower case alphabetic characters are to be treated identically.

The command codes and the argument fields are separated by one or more spaces. It should be noted that the server is to take no action until the end of line code is received.

Square brackets denote an optional argument field. If the option is not taken, the appropriate default is implied. As such, the user issues an FTP command and the server responds with a prompt primary reply. The user should wait for this initial primary success or failure response before sending further commands.

Certain commands require a second reply for which the user should also wait. These replies may, for example, report on the progress or completion of file transfer or the closing of the data connection. They are secondary replies to file transfer commands. One important group of informational replies is the connection greetings. Under normal circumstances, a server will send a reply, "awaiting input", when the connection is completed.

The user should wait for this greeting message before sending any commands. If the server is unable to accept input right away, a "expected delay" reply should be sent immediately and a reply when ready.

The user will then know not to hang up if there is a delay. Spontaneous Replies Sometimes "the system" spontaneously has a message to be sent to a user usually all users. For example, "System going down in 15 minutes". There is no provision in FTP for such spontaneous information to be sent from the server to the user.

It is recommended that such information be queued in the server-PI and delivered to the user-PI in the next reply possibly making it a multi-line reply. The table below lists alternative success and failure replies for each command. These must be strictly adhered to; a server may substitute text in the replies, but the meaning and action implied by the code numbers and by the specific command reply sequence cannot be altered.

Command-Reply Sequences In this section, the command-reply sequence is presented. Each command is listed with its possible replies; command groups are listed together. This listing forms the basis for the state diagrams, which will be presented separately. Only the first digit of the reply codes is used. There is one state diagram for each group of FTP commands or command sequences. The command groupings were determined by constructing a model for each command then collecting together the commands with structurally identical models.

For each command or command sequence there are three possible outcomes: success S , failure F , and error E. In the state diagrams below we use the symbol B for "begin", and the symbol W for "wait for reply". Note that this second model could also be used to represent the first group of commands, the only difference being that in the first group the series replies are unexpected and therefore treated as error, while the second group expects some may require series replies.

Remember that at most, one series reply is allowed per command. We note that the above three models are similar. The Restart differs from the Rename two only in the treatment of series replies at the second stage, while the second group expects some may require series replies.

The following may be a typical scenario. Server makes data connection to port U. The file system of TOPS is based on the concept of pages. The operating system is most efficient at manipulating files as pages.

The operating system provides an interface to the file system so that many applications view files as sequential streams of characters. However, a few applications use the underlying page structures directly, and some of these create holey files. A TOPS disk file consists of four things: a pathname, a page table, a possibly empty set of pages, and a set of attributes.

It includes the directory name, file name, file name extension, and generation number. If it is not empty, there are also some page-specific access bits; not all pages of a file need have the same access protection. A page is a contiguous set of words of 36 bits each. The attributes of the file, in the File Descriptor Block FDB , contain such things as creation time, write time, read time, writer's byte-size, end-of-file pointer, count of reads and writes, backup system tape numbers, etc.

Note that there is NO requirement that entries in the page table be contiguous. There may be empty page table slots between occupied ones. Also, the end of file pointer is simply a number. There is no requirement that it in fact point at the "last" datum in the file. In fact, in both of these special cases, "holey" files and end-of-file pointers NOT at the end of the file, occur with NLS data files.

Each page of information has a header. The header fields are: Word 0: Header Length. The header length is 5. Word 1: Page Index. If the data is a disk file page, this is the number of that page in the file's page map.

Empty pages holes in the file are simply not sent. Note that a hole is NOT the same as a page of zeros. Word 2: Data Length. The number of data words in this page, following the header.

Thus, the total length of the transmission unit is the Header Length plus the Data Length. Word 3: Page Type. A code for what type of chunk this is. A data page is type 3, the FDB page is type 2. Word 4: Page Access Control. The access bits associated with the page in the file's page map.

After the header are Data Length data words. Data Length is currently either for a data page or 31 for an FDB. Trailing zeros in a disk file page may be discarded, making Data Length less than in that case. RMD pathname Remove the directory with the name "pathname". PWD Print the current working directory name. CDUP Change to the parent of the current working directory. The "pathname" argument should be created removed as a subdirectory of the current working directory, unless the "pathname" string contains sufficient information to specify otherwise to the server, e.

The reply codes for MKD, however, are a bit more complicated. This is the case, for example, when a TOPS subdirectory is created by giving just the subdirectory name. The new directory may only be referred to by its "absolute" name; e. If it is a "relative" pathname i. Depending on the application, this may be inconvenient. It is not very robust in any case. Execute the following command.

Where your-package. By default, it can not be installed correctly. In other words, RPM — I — force — nodeps can ignore all dependency and file problems, what package.

Some packages end with. These packages are RPM packages that contain the source code. When installing, the. Using the command RPM — e package name, the package name can contain the version number and other information, but can not have the suffix. For example, to uninstall the software package proftpd