FILE SYSTEM - notes on the file system.

The File System (also known as FMS) is the set of routines that maintain permanent files and catalogs for both TSS and batch. (Temporary files are maintained in a different way.) To ask for services from the FMS system, you use the ACCESS command in TSS (see "expl access") and the $FILSYS card in batch (see "expl cc filsys").

This explain file will deal briefly with the various services provided by the file system and ways in which you might use these services profitably.

Permissions:

The FMS permission structure dictates which users are allowed access to particular files and catalogs. The structure also specifies what actions these users are allowed to perform (for example, are they allowed to write on a file or are they only allowed to read it).

Permissions are of two types: specific and general. General permissions apply to all users; for example, if a file has general read permission, any user on the system may read it. Specific permissions apply to individual users; for example, a file might have general read permissions plus specific write permissions for user "prabbit". Thus anyone could read the file but only "prabbit" could write to it.

General and specific permissions are attached to a file or a catalog when it is created. If you create a file using the FRED text editor, it will be given general read permissions AUTOMATICALLY unless you specify FRED's O-R option. Thus if you don't want a FRED file to be publically available, you must specify O-R. In most other situations where files are created, the files will not have any general or specific permissions unless you ask for them in some way.

The CLIS command can tell you what general and specific permissions are currently attached to a file or catalog. The output of CLIS has the form

file         ds7 s rwaemplcr  <other stuff>
     specific permissions
       prabbit     rwaemplcr

The first line starts with the name of the file, the device it's stored on (in this case ds7), whether it's sequential or random (the "s" here indicates sequential), and after that come the GENERAL permissions. The permissions are always listed in the order given; the individual letters have the following meanings.

r: read permission; indicates that the file may be read by permitted users.
w: write permission; indicates that permitted users may overwrite the contents of the file.
a: append permission; this may be the same as read.
e: execute permission; indicates that permitted users may execute the file. If a user has execute permission on a file or catalog, he will be able to use such commands as CLIS and LC on it.
m: modify permission; indicates that permitted users may modify the attributes of the file or catalog. This means that they may add or remove permissions, put on or change passwords, and so on.
p: purge permission; indicates that permitted users may delete the file or catalog.
l: lock permission; indicates that permitted users may read the contents of files even if they are security locked. Normal read permission is not enough to read security locked files. For more on locks, see below.
c: create permission; when attached to a catalog, indicates that permitted users may create files or subcatalogs under the catalog.
r: recovery permission; this is essentially the same as write permission except that it allows writing to take place even if the file is abort locked or contains defective space.

Some permissions imply others automatically; for example, read permission automatically brings with it execute permission, and write permission automatically brings with it read and execute permissions.

The CLIS output shows what permissions are included; for example,

cata         dx5  r  e
    specific permissions
      prabbit     rwae
      fbaggins    rwaemplcr

This indicates that "cata" has general read/execute permissions; "prabbit" has specific read/write/append/execute and "fbaggins" has all possible specific permissions.

If a file or catalog has no general permissions, CLIS will print the word "none" where the general permissions are usually listed.

The ACCESS command is used to create or change the permissions on files and catalogs. For further information see

expl access cc: creating catalogs with perms
expl access mc: modifying catalog perms
expl access cf: creating files with perms
expl access mf: modifying file perms
expl access perms: more on permissions

File Organization:

The file system organizes files into catalogs. Every user on the system has a master catalog entry whose name is the same as his userid. Underneath this catalog may be any number of files or subcatalogs. Every subcatalog may have subcatalogs of its own. Thus you obtain a type of tree structure:

               master catalog
                   /     \
          subcatalogs    files
            /     \
   subcatalogs   files

If user nbrazil has a file named "world" under a subcatalog called "of" under a catalog named "well", the file would be accessed using the PATHNAME "nbrazil/well/of/world".

Catalogs and subcatalogs should be used to organize your files. For example, you may put the source code for all your B programs under a catalog called B. Within this catalog there may be subcatalogs to organize the source files for various programs. By choosing descriptive names for your files and catalogs, you can obtain pathnames that give a great deal of information about your files; for example, a pathname like

dquixote/b/source/proga/manifests

obviously indicates B source code manifests for a program named "proga". This pathname is obviously longer than a name like "dquixote/x", but the small amount of extra typing is more than compensated for by the amount of information conveyed.

Permission Inheritance:

Files usually inherit permissions from the catalogs in which they are found. Thus if a catalog has general read permission, all the files under that catalog will also be available to the general public, whether or not they have explicit permissions associated with them individually. (This is why EXPL is available to all users -- the "expl" account has general read permission and therefore it is unnecessary to put read permissions on each individual explain file.)

Because files inherit permissions from catalogs, you should exercise a little caution in putting general permissions on catalogs.

Locks:

In addition to normal permissions, you may put a lock on any file or catalog. The two most important types of locks are security locks and write locks.

If a file or catalog has a security lock on it, it can only be accessed by someone with lock permission (see above). Thus if a catalog has general read permission, you can keep files under it private by putting security locks on them.

A write lock on a file prevents everyone from writing to the file. There is no way to remove a write lock. Thus a write lock is a very effective way of making sure that a file isn't accidentally ruined by overwriting.

For further information on locks, see "expl access efso" (extended file system options).

Passwords:

Passwords may be placed on any file or catalog using ACCESS. Once this has been done, people will only be allowed to access the file or catalog if they have the appropriate permissions and if they can supply the proper password. If there is a password on a file that is under a catalog that also has a password, you will have to supply the passwords for both the catalog and the file.