The Programmer's Guide to TRSDOS Version 6 - Tim Mann's Home ...

will only permit the opener to read the file, not to write to it. Any SuperVisor Call
request for updating, writing, renaming, or removing will return the "Attempt to access
protected file" error. If the OWNER password is part of the filespec when the file is
opened, the system will permit all levels of access regardless of any USER password or
protection level.
Prot Effect
NONE You cannot access the file. This PROT is used for system files.
EXEC You can only run the program file.
READ You can read the file.
UPDATE You can write to an existing file without extending it.
WRITE You can write to and extend the file.
RENAME You can change the name/extension of the file.
REMOVE You can delete the file from the disk.
FULL You can change the protection level and passwords of the file.
Note: Each level grants the access listed above it.
Figure 6-1 Access protection levels
Passwords are assigned to files in one of two ways. If a password is part of the filespec
when the file is first created with the @INIT SuperVisor Call function, then that
password will become both the OWNER and USER passwords. The protection level will be FULL
but since both password fields are in use, the password must be entered for any access to
the file. The second method of applying password protection is to use the ATTRIB library
command. This command allows you to change both passwords and protection level - assuming
you have the access authority based on the file's existing protection.
A password can be composed of nothing but blanks. This is in effect, no password at all
since the entry of NOTHING is interpreted as a blank field and thus will grant access
according to the level associated with the password field. For instance, if the OWNER
password field is blank, the file has no protection whatsoever even if the USER password
field is non-blank because a filespec without a password entry will match the blank OWNER
password thus granting full access. It is important for the OWNER password to be nonblank
if the file is to be protected in any manner.
A common situation is to find the OWNER password kept private to those individual(s)
either maintaining the application or responsible for the integrity of the file contents
while providing a blank USER password with a protection level set to the minimum level of
access needed by the user. For instance, if the user only needs to read a file, set the
protection level to READ. This user can then read the file without having to bother with
a password but that user cannot write to the file, cannot remove it from the disk, cannot
rename the file, nor can the user change the protection level of the file. However, the
maintainer can step in to deal with file maintenance at a higher level of access given
the OWNER password.
Where use of a file needs to be restricted to an individual out of a group of
individuals, then the USER password field should have a non-blank password that is
distinct from the OWNER password. The access protection level is still kept to the
minimum necessary for the user. This scenario will then permit that individual the
minimum access to the file while excluding all others (unless, of course, the user shares
his knowledge of the password with others).
It may be practical for any given installation to consider protecting all files to the
minimum access level expected of them. Thus any file whose primary access is READ only
would be protected accordingly. There will be less chance to inadvertently remove the
file by mistake or mistakenly write to it - a common error when dealing with applications
that frequently prompt the user for the entry of file specifications.
6-5