In order to perform any action on a CNode, the AFP client must designate a path to the CNode. AFP provides rules for specifying a path to any CNode in the volume catalog. A CNode (file or directory) can be unambiguously specified to the server by the identifiers shown in Figure 1-3.
The Volume ID specifies the volume on which the destination CNode resides. The Directory ID can belong to the destination CNode (if the CNode is a directory) or to any one of its ancestor directories, up to and including the root directory and the root’s parent directory.
An AFP pathname is formatted as a Pascal string (one length byte followed by the number of characters specified by the length byte) or a UTF-8 string (a four-byte text encoding hint followed by two length bytes followed by the number of characters specified by the length bytes). An AFP pathname is made up of CNode names, concatenated with intervening null-byte separators. Each element of a pathname must be the name of a directory, except for the last one, which can be the name of a directory or a file.
The elements of a pathname can be Long or Short Names. However, a given pathname cannot contain a mixture of Long and Short Names. A path type byte, which indicates whether the elements of the pathname are all Short or all Long Names, is associated with each pathname. A pathname consisting of Short Names and a path type of 1. A pathname consisting of Long Names has a path type of 2.
An AFP pathname that consists of Long or Short Names can be up to 255 characters long. The length of an AFP pathname that consists of UTF-8–encoded names is virtually unlimited. A single null byte as the length byte indicates that no pathname is supplied. Because the length byte is included at the beginning of the string, each pathname element (CNode name) does not include a length indicator.
The syntax of an AFP pathname follows this paragraph. The asterisk (*) represents a sequence of zero or more of the preceding elements of the pathname; the plus (+) represents a sequence of one or more of the preceding elements; <Sep> represents the separators in the pathname; the vertical bar (|) is an OR operator; and the term on the left side of the ::= symbol is defined as the term(s) on the right side.
<Sep> ::= <null-byte>+ |
<Pathname> ::= empty-string | |
<Sep>*<CNode name>(<Sep><Pathname>* |
The syntax represents a concatenation of CNode names separated by one or more null bytes. Pathnames can also start or end with a string of null bytes.
A pathname can be used to traverse the volume catalog in any direction. The pathname syntax allows paths either to descend from a particular CNode through its offspring or to ascend from a CNode to its ancestors. In either case, the directory that is the starting point of this path is defined separately from the pathname by its Directory ID. The first element of the pathname is an offspring of the starting point of the directory. The pathname must be parsed from left to right to obtain each element that is used as the next node on the path.
To descend through a volume, a valid pathname must proceed in order from parent to offspring. A single null-byte separator preceding this first element is ignored.
To ascend through a volume, a valid pathname must proceed from a particular CNode to its ancestor. To ascend one level in the catalog tree, two consecutive null bytes should follow the offspring CNode name. To ascend two levels in the catalog tree, three consecutive null bytes are used as the separator, and so on.
A particular volume may descend and ascend through the volume catalog. Because of this, many valid pathnames may refer to the same CNode.
A complete path specification can take a number of forms. The table that follows summarizes the different kinds of path specifications that can be used to traverse the volume catalog illustrated in Figure 1-4. A zero in square brackets [0] represents a null-byte separator.
The descriptors and examples that follow refer to this table and the corresponding volume catalog illustrated in Figure 1-4. To simplify these examples, the CNodes in this catalog are named a through j, except the root, which is named x. The path type is ignored in this example. The letter v represents the volume’s two-byte Volume ID. Lines connect the CNodes; the unconnected lines indicate that other CNodes in this volume are not shown.
Table 1-11 provides the Volume ID, Directory ID, and pathname for some sample path specifications in Figure 1-4.
Example | Volume ID | Directory IDs | Pathname |
|---|---|---|---|
First | v | 2 | a[0]c[0]e[0]j[o] |
Second | v | 104 | e[0]j |
Third | v | 106 | [0]j |
Fourth | v | 106 | j |
Fifth | v | 106 | [0] |
Sixth | v | 104 | e[0][0]g[0][0]h |
Seventh | v | 104 | e[0][0][0] |
Eighth | v | 1 | x[0]a[0]c[0]h |
The first example of a path specification in Table 1-11 contains the Volume ID, the root directory’s Directory ID, which is always 2, and a pathname. In this case, the pathname must contain the names of all of the destination file’s ancestors except the root, and it must end with the name of the file itself. The single trailing null byte is ignored.
The second example contains the Volume ID, the Directory ID of an ancestor, and a pathname.
The third example is essentially the same as the second example. The single leading null byte is ignored.
In the fourth example, the Directory ID is the Parent ID of the destination file. In this case, the pathname need contain only the name of the destination file itself.
The fifth example illustrates another way to uniquely specify a descending path to a directory. It includes the CNode’s Volume ID, its Directory ID, and a null pathname. This path specification is used to specify the directory e.
The sixth example illustrates a descending path. The first CNode in the pathname is the offspring of the starting point Directory ID. Then the pathname ascends though e’s parent (c) down to directory g, backup to g’s parent (c), and down again to h.
The seventh shows an ascending pathname that starts at directory c (whose Directory ID is 104), moves down to e, and then ascends to e’s parent’s parent (a).
The eighth example is a special case in which the starting point of the path is Directory ID 1, the parent of the root. The first name of the pathname must be the volume name or root directory name corresponding to Volume ID v; beyond that, pathname traversal is performed as in the other examples.
Last updated: 2006-04-04