10] may be used in a TVFS file name. When transmitted, file name characters are encoded using the UTF-8 encoding . Note that the two-character sequence CR LF occurring in a file name will make that name impossible to transmit over a data connection. Consequently, it should be avoided, or if that is impossible to achieve, it MUST be encoded in some reversible way.
Where a pathname has been extended to the point where the directory added is the unnamed root directory, the pathname will begin with the "/" character. Such a path is known as a fully qualified pathname. Fully qualified paths may, obviously, not be further extended, as, by definition, no directory contains the root directory. Being unnamed, it cannot be represented in any other directory. A fully qualified pathname is valid to reference the named file or directory from any location (that is, regardless of what the current working directory may be) in the virtual file store. Any pathname that is not a fully qualified pathname may be referred to as a "relative pathname" and will only correctly reference the intended file when the current working directory of the server-FTP is a directory from which the relative pathname is valid. As a special case, the pathname "/" is defined to be a fully qualified pathname referring to the root directory. That is, the root directory does not have a directory (or file) name, but does have a pathname. This special pathname may be used only as is as a reference to the root directory. It may not be combined with other pathnames using the rules above, as doing so would lead to a pathname containing two consecutive "/" characters, which is an undefined sequence.
subset supported is entirely at the discretion of the server. The case (where it exists) of the characters that make up file, directory, and pathnames may be significant. Unless determined otherwise by means unspecified here, clients should assume that all such names are comprised of characters whose case is significant. Servers are free to treat case (or any other attribute) of a name as irrelevant, and hence map two names that appear to be distinct onto the same underlying file. + There are no defined "magic" names, like ".", ".." or "C:". Servers may implement such names, with any semantics they choose, but are not required to do so. + TVFS imposes no particular semantics or properties upon files, guarantees no access control schemes, or any of the other common properties of a file store. Only the naming scheme is defined. 6] a server that wishes to indicate support for the TVFS as defined here will include a line that begins with the four characters "TVFS" (in any case, or mixture of cases, upper case is not required). Servers SHOULD send upper case. Such a response to the FEAT command MUST NOT be returned unless the server implements TVFS as defined here. Later specifications may add to the TVFS definition. Such additions should be notified by means of additional text appended to the TVFS feature line. Such specifications, if any, will define the extra text. Until such a specification is defined, servers should not include anything after "TVFS" in the TVFS feature line. Clients, however, should be prepared to deal with arbitrary text following the four defined characters, and simply ignore it if unrecognized. A typical response to the FEAT command issued by a server implementing only this specification would be: C> feat S> 211- <any descriptive text> S> ... S> TVFS S> ... S> 211 end
The ellipses indicate place holders where other features may be included, but are not required. The one-space indentation of the feature lines is mandatory  and is not counted as one of the first four characters for the purposes of this feature listing. The TVFS feature adds no new commands to the FTP command repertoire.
It is clear that none of the paths / /A /B or /A/D refer to the same directory, as the contents of each is different. Nor do any of / /A /A/C or /A/D. However /A/C and /B might be the same directory, there is insufficient information given to tell. Any of the other pathnames (/X /Y /A/Z /A/C/P /A/C/Q /B/P and /B/Q) may refer to the same underlying files, in almost any combination. If the current working directory of the server-FTP is /A then the following pathnames, in addition to all the fully qualified pathnames, are valid C D Z C/P C/Q These all refer to the same files or directories as the corresponding fully qualified path with "/A/" prepended. That those pathnames all exist does not imply that the TVFS sever will necessarily grant any kind of access rights to the named paths, or that access to the same file via different pathnames will necessarily be granted equal rights. None of the following relative paths are valid when the current directory is /A A B X Y B/P B/Q P Q Any of those could be made valid by changing the server-FTP's current working directory to the appropriate directory. Note that the paths "P" and "Q" might refer to different files depending upon which directory is selected to cause those to become valid TVFS relative paths.
STD 9, RFC 959  and STD 3, RFC 1123  to allow that transmission of 8-bit data over the control connection. Note this is not specifying character sets which are 8-bit, but specifying that FTP implementations are to specifically allow the transmission and reception of 8-bit bytes, with all bits significant, over the control connection. That is, all 256 possible octet values are permitted. The MLSx command allows both UTF-8/Unicode and "raw" forms as arguments, and in responses both to the MLST and MLSD commands, and all other FTP commands which take pathnames as arguments.
file or directory names (not pathnames) the server-PI will allow to be referenced when the current working directory is the directory named, and which the server-PI desires to reveal to the user-PI. Note that omitting the argument is the only defined way to obtain a listing of the current directory, unless a pathname that represents the directory happens to be known. In particular, there is no defined shorthand name for the current directory. This does not prohibit any particular server-PI implementing such a shorthand. No title, header, or summary, lines, or any other formatting, other than as is specified below, is ever returned in the output of an MLST or MLSD command. If the Client-FTP sends an invalid argument, the server-FTP MUST reply with an error code of 501. The syntax for the MLSx command is: mlst = "MLst" [ SP pathname ] CRLF mlsd = "MLsD" [ SP pathname ] CRLF
local-fact = "X." token value = *SCHAR Upon receipt of an MLSx command, the server will verify the parameter, and if invalid return an error-response. For this purpose, the parameter should be considered to be invalid if the client issuing the command does not have permission to perform the requested operation. If the parameter is valid, then for an MLST command, the server-PI will send the first (leading) line of the control response, the entry for the pathname given, or the current directory if no pathname was provided, and the terminating line. Normally exactly one entry would be returned, more entries are permitted only when required to represent a file that is to have multiple "Type" facts returned. In this case, the pathname component of every response MUST be identical. Note that for MLST the fact set is preceded by a space. That is provided to guarantee that the fact set cannot be accidentally interpreted as the terminating line of the control response, but is required even when that would not be possible. Exactly one space exists between the set of facts and the pathname. Where no facts are present, there will be exactly two leading spaces before the pathname. No spaces are permitted in the facts, any other spaces in the response are to be treated as being a part of the pathname. If the command was an MLSD command, the server will open a data connection as indicated in section 3.2 of STD 9, RFC 959 . If that fails, the server will return an error-response. If all is OK, the server will return the initial-response, send the appropriate data-response over the new data connection, close that connection, and then send the final-response over the control connection. The grammar above defines the format for the data-response, which defines the format of the data returned over the data connection established. The data connection opened for a MLSD response shall be a connection as if the "TYPE L 8", "MODE S", and "STRU F" commands had been given, whatever FTP transfer type, mode and structure had actually been set, and without causing those settings to be altered for future commands. That is, this transfer type shall be set for the duration of the data connection established for this command only. While the content of the data sent can be viewed as a series of lines, implementations should note that there is no maximum line length defined. Implementations should be prepared to deal with arbitrarily long lines.
The facts part of the specification would contain a series of "file facts" about the file or directory named on the same line. Typical information to be presented would include file size, last modification time, creation time, a unique identifier, and a file/directory flag. The complete format for a successful reply to the MLSD command would be: facts SP pathname CRLF facts SP pathname CRLF facts SP pathname CRLF ... Note that the format is intended for machine processing, not human viewing, and as such the format is very rigid. Implementations MUST NOT vary the format by, for example, inserting extra spaces for readability, replacing spaces by tabs, including header or title lines, or inserting blank lines, or in any other way alter this format. Exactly one space is always required after the set of facts (which may be empty). More spaces may be present on a line if, and only if, the pathname presented contains significant spaces. The set of facts must not contain any spaces anywhere inside it. Facts should be provided in each output line only if they both provide relevant information about the file named on the same line, and they are in the set requested by the user-PI. See section 7.9 (page 51). There is no requirement that the same set of facts be provided for each file, or that the facts presented occur in the same order for each file. section 4.2 of STD 9, RFC 959  are possible in response to the MLST and MLSD commands. In particular, syntax errors can generate 500 or 501 replies. Giving a pathname that exists but is not a directory as the argument to a MLSD command generates a 501 reply. Giving a name that does not exist, or for which access permission (to obtain directory information as requested) is not granted will elicit a 550 reply. Other replies (530, 553, 503, 504, and any of the 4xy replies) are also possible in appropriate circumstances.
names. FTP implementations SHOULD use UTF-8 whenever possible to encourage the maximum inter-operability. File names are not restricted to UTF-8, however treatment of arbitrary character encodings is not specified by this standard. Applications are encouraged to treat non-UTF-8 encodings of file names as octet sequences. Note that this encoding is unrelated to that of the contents of the file, even if the file contains character data. Further information about file name encoding for FTP may be found in "Internationalization of the File Transfer Protocol" . section 6.2.
Alternatively, whether TVFS is supported or not, the user-PI can issue a CWD command () giving a name of type "cdir" from the listing returned, and from that point reference the files returned in the MLSD response from which the cdir was obtained by using the file name components of the listing. section 2.1 for a list of the characters that can occur in a fact value. Not all are applicable to all facts. A sample of a typical series of facts would be: (spread over two lines for presentation here only) size=4161;lang=en-US;modify=19970214165800;create=19961001124534; type=file;x.myfact=foo,bar; 11] registry. media-type -- MIME media-type of file contents per IANA registry. charset -- Character set per IANA registry (if not UTF-8) Fact names are case-insensitive. Size, size, SIZE, and SiZe are the same fact. Further operating system specific keywords could be specified by using the IANA operating system name as a prefix (examples only): OS/2.ea -- OS/2 extended attributes MACOS.rf -- MacIntosh resource forks UNIX.mode -- Unix file modes (permissions)
Implementations may define keywords for experimental, or private use. All such keywords MUST begin with the two character sequence "x.". As type names are case independent, "x." and "X." are equivalent. For example: x.ver -- Version information x.desc -- File description x.type -- File type
type fact is included, and provides a name for the listed directory, and facts about that directory. In a sense, it can be viewed as representing the title of the listing, in a machine friendly format. It may appear at any point of the listing, it is not restricted to appearing at the start, though frequently may do so, and may occur multiple times. It MUST NOT be included if the type fact is not included, or there would be no way for the user-PI to distinguish the name of the directory from an entry in the directory. Where TVFS is supported by the server-FTP, this name may be used to construct pathnames with which to refer to the files and directories returned in the same MLSD output (see section 6.2). These pathnames are only expected to work when the server-PI's position in the NVFS file tree is the same as its position when the MLSD command was issued, unless a fully qualified pathname results. Where TVFS is not supported, the only defined semantics associated with a "type=cdir" entry are that, provided the current working directory of the server-PI has not been changed, a pathname of type "cdir" may be used as an argument to a CWD command, which will cause the current directory of the server-PI to change so that the directory that was listed in its current working directory.
For the purposes of this type value, a "parent directory" is any directory in which there is an entry of type=dir that refers to the directory in which the type=pdir entity was found. Thus it is not required that all entities with type=pdir refer to the same directory. The "unique" fact (if supported and supplied) can be used to determine whether there is a relationship between the type=pdir entries or not. section 10. The "os-kind" provides the system dependent information as to the type of the file listed. The os-name and os-kind strings in an os-type are case independent. "OS.unix=block" and "OS.Unix=BLOCK" represent the same type (or would, if such a type were registered.) Note: Where the underlying system supports a file type that is essentially an indirect pointer to another file, the NVFS representation of that type should normally be to represent the file that the reference indicates. That is, the underlying basic file will appear more than once in the NVFS, each time with the "unique" fact (see immediately following section) containing the same value, indicating that the same file is represented by all such names. User-PIs transferring the file need then transfer it only once, and then insert their own form of indirect reference to construct alternate names where desired, or perhaps even copy the local file if that is the only way to provide two names with the same content. A file which would be a reference to another file, if only the other file actually existed, may be represented in any OS dependent manner appropriate, or not represented at all.
treated as a unit, or treated as a directory allowing the sub-files within it to be referenced. When this is done, the pathname returned with each entry MUST be identical to the others representing the same file.
command naming the object should succeed, and the user should be able to enter the directory named. For type=pdir it also indicates that the CDUP command may succeed (if this particular pathname is the one to which a CDUP would apply.) The "f" permission for objects indicates that the object named may be renamed - that is, may be the object of an RNFR command. The "l" permission applies to the directory file types, and indicates that the listing commands, LIST, NLST, and MLSD may be applied to the directory in question. The "m" permission applies to directory types, and indicates that the MKD command may be used to create a new directory within the directory under consideration. The "p" permission applies to directory types, and indicates that objects in the directory may be deleted, or (stretching naming a little) that the directory may be purged. Note: it does not indicate that the RMD command may be used to remove the directory named itself, the "d" permission indicator indicates that. The "r" permission applies to type=file objects, and for some systems, perhaps to other types of objects, and indicates that the RETR command may be applied to that object. The "w" permission applies to type=file objects, and for some systems, perhaps to other types of objects, and indicates that the STOR command may be applied to the object named. Note: That a permission indicator is set can never imply that the appropriate command is guaranteed to work -- just that it might. Other system specific limitations, such as limitations on available space for storing files, may cause an operation to fail, where the permission flags may have indicated that it was likely to succeed. The permissions are a guide only. Implementation note: The permissions are described here as they apply to FTP commands. They may not map easily into particular permissions available on the server's operating system. Servers are expected to synthesize these permission bits from the permission information available from operating system. For example, to correctly determine whether the "D" permission bit should be set on a directory for a server running on the UNIX(TM) operating system, the server should check that the directory named is empty, and that the user has write permission on both the directory under consideration, and its parent directory.
Some systems may have more specific permissions than those listed here, such systems should map those to the flags defined as best they are able. Other systems may have only more broad access controls. They will generally have just a few possible permutations of permission flags, however they should attempt to correctly represent what is permitted. 12] for the syntax, and procedures, related to language tags. lang-fact = "Lang" "=" token Server-FTP implementations MUST NOT guess language values. Language values must be determined in an unambiguous way such as file system tagging of language or by user configuration. Note that the lang fact provides no information at all about the content of a file, only about the encoding of its name. section 4. The most common need for this accuracy is likely to be in conjunction with the REST command described in section 5. The size fact, on the other hand, should be used for purposes such as indicating to a human user the approximate size of the file to be transferred, and perhaps to give an idea of expected transfer completion time. size-fact = "Size" "=" 1*DIGIT