1.2 Pathname Resolution

A path string identifies the final target file object.

The following sections provide examples and descriptions of various paths:

If no context information is specified, the string must be a fully qualified path. If a path context was used, this path information is relative to the file object that was previously identified by the context information. However, if this path begins with a single backslash (\) character, the path is considered to be relative to the root of the volume identified by the key. (The above examples are using the path separators for the DOS and LONG namespaces. The path separators might vary for other namespaces.)

In the DOS and LONG namespaces, if the path begins with a volume name followed by a colon, the volume name must be local on the server parsing the path. The remaining portion of the path is considered to be relative to that volume.

AFPTCP works properly with the zAPIs in the Macintosh* and UNIX* namespaces. However, volume names need to be resolved in the LONG or DOS namespace.

1.2.1 Fully Qualified Paths

The following is an example of a fully qualified path that is relative to a volume name:

myvolume:users\brenda\myfile.dat

The first name (up to the colon) identifies a volume that must exist on the local server that is parsing the path. The remainder of the path is relative to the root of the specified volume. This type of path ignores any file object information identified by the key. It always specifies to begin parsing at the root of the identified volume.

1.2.2 Relative Paths

To be legal, the volume and starting directory information must have been previously identified in a relative path by using a key. The following is an example of a relative path:

brenda\myfile.dat

Volume Root Relative Path

The following is an example of a path that is relative to the root of a volume:

\users\brenda\myfile.dat

This type of path ignores any file object information identified by a context handle. It always specifies to begin parsing at the root of the identified volume.

Datastream Relative Path

The following is an example of a relative path that identifies a data stream that is named mydatastream of the myfile.dat file:

brenda\myfile.dat:mydatastream

Extended Attribute Relative Path

The following is an example of a relative path that identifies an extended attribute that is named myextendedattribute of the myfile.dat file:

brenda\myfile.dat::myextendedattribute

Relative Directory Sequences

The following is an example of a relative path that uses relative directory movement sequences. In this case, the neal directory must be a sibling directory of the brenda directory that contains the hisfile.dat file.

brenda\..\neal\hisfile.dat

1.2.3 Namespace Considerations

To tell the system which characters are legal, which characters are wild, or if the names are case insensitive, the namespace must be specified. Some other characteristics of the path are defaulted, but the following mode bits override any defaults:

zMODE_UTF8

The default character set for the path is Unicode*. However, by ORing zMODE_UTF8, UTF-8 character strings can be used.

zMODE_DELETED

Changes the name scanning to look for deleted files in the salvage system.

zMODE_LINK

If the last name in the path is a symbolic link, a junction, or URL link, the scanning does not follow the link but acts on the link object itself.

Path components are separated by the standard path separator characters for that namespace. Wildcards and relative directory sequences (such as \..\..) are also represented in the native client’s namespace format.

In addition to the standard separators, the DOS and LONG namespaces recognize a colon (:) following a slash as being a data stream name separator. They recognize a double colon (::) following anywhere after a slash as being an extended attribute name separator.

1.2.4 Wildcards

The last leaf name in a path can optionally contain wildcards. Wildcards are supported only by the DOS and LONG namespaces and allow operations like zRename and zDelete to operate on multiple files with one request. The DOS and LONG namespaces share a common syntax, with the following wildcards:

Asterisk (simple Unicode or UTF-8 *)

An asterisk matches any character or sequence of characters except for periods. If a period is encountered in the filename, it is not matched by an asterisk. The matching pattern must contain an explicit period or another wildcard character that matches periods in order to proceed beyond the period. If the asterisk occurs at the end of a wildcard pattern or before a period, it matches a null string.

Question mark (simple Unicode or UTF-8 ?)

A question mark matches any single character except for a period. If a period is encountered in the filename, it is not matched by a question mark. The matching pattern must contain an explicit period or another wildcard character that matches the period in order to proceed beyond the period. If the question mark occurs at the end of a wildcard pattern or before a period, it matches a null string.

Period (simple Unicode or UTF-8 .)

A period matches a single period in the file name to be matched. If the period occurs at the end of the matching pattern, it also matches a null string