Text-only	Table of Contents (frame/ no frame)
(8) Filesystem layout

Figure 4. AFS filesystem layout. Red outlines are volume mount points. Black outlines are plain directories.

User accounts are initally set up with two directories named private and public. To facilitate file sharing between colleagues, the public directory allows public read access. All parent directories in the AFS hierarchy must allow a minmum of lookup access to allow this to be used. This allows file names to be seen, but not contents. The private directory is completely protected from all users other than the owner. Changing the AFS ACL on a home directory is strongly discouraged as various administrative functions may break. Newly created directories will inherit the public lookup ACL of the parent, allowing any user to see the file names. Completely private directories can be created with the 'fs setacl' command, or inside of the 'private' directory.

The non-local cells have been split off to /afs/worldwide in order to improve performance of GUI file managers which often try to retrieve information for every pathname component from the root down. Listing /afs/worldwide is generally slow and may hang for long network timeouts if remote cells are offline.

Special pathnames

• /afs/@cell is a symbolic link to the local cell name , for convenience. (/afs/northstar.dartmouth.edu)
• /afs/northstar is a symbolic link to the fully qualified domain name, for convenience.
• .../@sys/... in a pathname is replaced by the client architecture type (e.g. sgi_65 for IRIX 6.5 on SGI computers). This feature can be used to automatically select the correct set of executables or configuration files for an application. For example, the system default .cshrc and .login files will initialize the $PATH variable with architecture-specific personal bin directories.