This section explains the file, path and directory names usage in STDLIB.
The Symbian platform file system APIs require all file names to be fully specified, possibly by using default components in the session path. For more information, see the documentation on the file server (File server). In particular, the file system does not support the notion of a "relative path" which uses "." and ".." to navigate relative to a "current working directory". STDLIB does support this and does not require fully qualified paths, with the constraint that any pathname beginning with "<letter> :" will be treated as an absolute path from the root of the specified drive. STDLIB allows the drive letter '?' to mean "any drive". This can be useful when a file or directory is known to exist but it could be on any drive. STDLIB allows both "/" and "\" as directory separators, unlike the underlying Symbian file system which recognises only "\".
The current working directory is a process-wide resource (similar to the file descriptor table), so the CPosixServer will provide a single process-wide current working directory. However, when using the "single-threaded" mode of operation, each thread will have a separate current working directory.
The following table gives some examples, all based on a working directory of c:\documents\stdlib
Pathname | In Symbian platform | In STDLIB |
| current directory | current directory |
| illegal (not a file) | current directory |
| illegal | current directory |
| illegal | c:\documents |
| filename | c:\documents\stdlib\examples |
| illegal | c:\documents\examples |
| illegal | d:\examples |
| illegal | c:\system\data (if file exists on c) or d:\system\data (if it exists on d but not on c) or z:\system\data (if it exists in the ROM). |
In summary, the POSIX and STDLIB handling of pathnames is DOS-like, with the exception that there is not a separate working directory per drive.
The Symbian file system supports DOS-like attributes, rather than POSIX-like permissions. STDLIB cannot therefore provide the full POSIX-like handling of file attributes and implements only "user read permission".
STDLIB's implementation of fseek(), unlike some other implementations, does not allow you to seek beyond the end of a file and expand the file to the new position.