Traditionally, FTP has placed almost no constraints upon the file
store (NVFS) provided by a server. This specification does not alter
that. However, it has become common for servers to attempt to
provide at least file system naming conventions modeled loosely upon
those of the UNIX(TM) file system. This is a tree-structured file
system, built of directories, each of which can contain other
directories, or other kinds of files, or both. Each file and
directory has a name relative to the directory that contains it,
except for the directory at the root of the tree, which is contained
in no other directory, and hence has no name of its own.
That which has so far been described is perfectly consistent with the
standard FTP NVFS and access mechanisms. The "CWD" command is used
to move from one directory to an embedded directory. "CDUP" may be
provided to return to the parent directory, and the various file
manipulation commands ("RETR", "STOR", the rename commands, etc.) are
used to manipulate files within the current directory.
However, it is often useful to be able to reference files other than
by changing directories, especially as FTP provides no guaranteed
mechanism to return to a previous directory. The Trivial Virtual
File Store (TVFS), if implemented, provides that mechanism.
6.1. TVFS File Names
Where a server implements the TVFS, no elementary file name shall
contain the character "/". Where the underlying natural file store
permits files, or directories, to contain the "/" character in their
names, a server-PI implementing TVFS must encode that character in
some manner whenever file or directory names are being returned to
the user-PI, and reverse that encoding whenever such names are being
accepted from the user-PI.
The encoding method to be used is not specified here. Where some
other character is illegal in file and directory names in the
underlying file store, a simple transliteration may be sufficient.
Where there is no suitable substitute character a more complex
encoding scheme, possibly using an escape character, is likely to be
required.
With the one exception of the unnamed root directory, a TVFS file
name may not be empty. That is, all other file names contain at
least one character.
With the sole exception of the "/" character, any valid IS10646
character [10] may be used in a TVFS file name. When transmitted,
file name characters are encoded using the UTF-8 encoding [2]. 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.
6.2. TVFS Pathnames
A TVFS "Pathname" combines the file or directory name of a target
file or directory, with the directory names of zero or more enclosing
directories, so as to allow the target file or directory to be
referenced other than when the server's "current working directory"
is the directory directly containing the target file or directory.
By definition, every TVFS file or directory name is also a TVFS
pathname. Such a pathname is valid to reference the file from the
directory containing the name, that is, when that directory is the
server-FTP's current working directory.
Other TVFS pathnames are constructed by prefixing a pathname by a
name of a directory from which the path is valid, and separating the
two with the "/" character. Such a pathname is valid to reference
the file or directory from the directory containing the newly added
directory name.
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.
6.2.1. Notes
+ It is not required, or expected, that there be only one fully
qualified pathname that will reference any particular file or
directory.
+ As a caveat, though the TVFS file store is basically tree
structured, there is no requirement that any file or directory
have only one parent directory.
+ As defined, no TVFS pathname will ever contain two consecutive "/"
characters. Such a name is not illegal however, and may be
defined by the server for any purpose that suits it. Clients
implementing this specification should not assume any semantics
for such names.
+ Similarly, other than the special case path that refers to the
root directory, no TVFS pathname constructed as defined here will
ever end with the "/" character. Such names are also not illegal,
but are undefined.
+ While any legal IS10646 character is permitted to occur in a TVFS
file or directory name, other than "/", server FTP implementations
are not required to support all possible IS10646 characters. The
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.3. FEAT Response for TVFS
In response to the FEAT command [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 [6] 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.
6.4. OPTS for TVFS
There are no options in this TVFS specification, and hence there is
no OPTS command defined.
6.5. TVFS Examples
Assume a TVFS file store is comprised of a root directory, which
contains two directories (A and B) and two non-directory files (X and
Y). The A directory contains two directories (C and D) and one other
file (Z). The B directory contains just two non-directory files (P
and Q) and the C directory also two non-directory files (also named P
and Q, by chance). The D directory is empty, that is, contains no
files or directories. This structure may depicted graphically as...
(unnamed root)
/ | \ \
/ | \ \
A X B Y
/|\ / \
/ | \ / \
C D Z P Q
/ \
/ \
P Q
Given this structure, the following fully qualified pathnames exist.
/
/A
/B
/X
/Y
/A/C
/A/D
/A/Z
/A/C/P
/A/C/Q
/B/P
/B/Q
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.
