$a invert=0
$a page=64; left=5; line=80; bottom=4; top=2
$a just=1; mark=2
$a cap=0; capsh=0; und=0

$b1 $l1cmu
A Note on the New Filestores' Facilities

$b1 $l1m
George D$.M$. Ross, 04/12/86

$p1 The task of redesigning the Department's dedicated file servers has now
progressed to the point where it will shortly be possible to offer a trial
service to users.  This note is therefore intended to give an idea of the
facilties to be offered by the new servers, and to indicate how they differ
from those offered by the current (old-style) Filestores.  More detailed
user documentation will be available at that time.

$p1 It should be pointed out that the new servers have been designed and
implemented from scratch and that total compatibility with the current
Filestores is not guaranteed, though every effort has been made to achieve
compatibilty where this would not have adversely affected the overall
design.


$b2 $l1u
File System and Directory Structure

$p1 The most obvious enhancement is that the new servers have a fully
hierarchic directory structure, in contrast to that of the current
Filestores, with users being able to create their own (sub-)directories,
subject of course to their overall total file size quota.  Filename
components can consist of any combination of up to 127 printing characters,
with upper and lower case alphabetic being considered equivalent (of course
some of these may also be treated as metacharacters by the client system).
Rather than the '!'-files of the current Filestores, the new servers
maintain (numbered) versions of files.  In addition,
the new servers allow for textual substitutions to appear as directory entries,
when they will be applied to the (remaining) path during translation.  Both
intra-server and inter-server substitutions are allowed, with the former
being interpreted within the server, while the latter are returned to the
client for interpretation, thus allowing the client to present
an extended cross-server directory structure to the user.

$p1 The protection mechanism has been extended to incorporate the notion of
groups of users.  In addition to owner, local (i.e. referring to a
co-resident client) and world protection, additional rights may be granted
to individual users and groups of users, while each user may belong to a
number of groups.  Access may be permitted or denied by means of this
mechanism.  Access rights are determined in the following way: grant world
access rights, local access rights if applicable,
enhanced or reduced by the various applicable group access rights
applied in the order in which they are defined, finally enhanced by the owner
access rights.  As an aid to course
administrators, there is the additional notion of a "supervisor" with the
same authority with respect to files as has their owner, with the
supervisor's identity being defined in a user's authorisation record.  In
practice, there would probably be several members of a supervisory group,
with one such group being defined for each identifiable body of students.

$p1 The protection classes defined are: read, modify, append, exchange, link,
and control access (append and exchange will not initially be available).  Read
access allows the user to read a file.  Modify access allows a user to alter an
existing file and to create a new version of a file (subject to having modify
access to the parent directory).  Append access will allow the user to append
new data to a file but not to read or modify old data.  Exchange access will
allow the user to (logically) swap the contents of two files as an atomic
operation.  Link access allows the user to insert and remove directory entries
for the file (a file is deleted when there are no more directory entries
referring to it).  Control access allows the user to change a file's
attributes (the owner and supervisor always have implicit control access).


$v6 $b2 $l1u
Protocols

$p1 The new servers are designed in such a way as to facilitate the use of
a number of file access (and indeed transport) protocols in parallel.  In
particular, they will support the current 1976-protocol as used by the
old-style Filestores and the current Fred-machine system, at least until
such time as the Fred-machine system can be adapted (rewritten) to use the
proposed new file access protocols.  In any case, the fact that the (slow)
ether protocols will be converted to recognised standards (ISO and TCP/IP),
and the bridging together of the fast and slow ethers,
would require some change in both the servers and the clients.

$p1 The advantages of new protocols
include: improved throughput (the current protocol is strictly
half-duplex); greater flexibility (with request options being more easily
specified); the ability to log on once only to a one of a number of
authorisation
points, giving users full access to all their files wherever they (the
users and the files) happen to be
located;
and the unification of the department's various file systems
(including ECSVAX and the various UNIX systems) into a single directory
structure, as perceived by the user, this latter being made possible by the
inter-server redirections and the universal acceptability of the new-style
authority tokens.  The new protocols do not assume, however, that the
client is trustworthy, as indeed they could not in an environment such as
ours.

$p1 Historically, of course, the Filestores served a mixed population of
clients, and it is only with the introduction of the (slow) ether as the
sole communications mechanism that the
client population was restricted to the Fred-machines.  It is anticpated
that with the conversion of the (slow) ether to use standard transport
protocols and the advent of the fast/slow ether bridge, that the client
base can once again be expanded.  It is certainly intended to expand the
number and type of servers to include the department's multi-access
systems, thus making users' files available to all clients wherever they
may be located.


$v6 $b2 $l1u
Client System Changes

$p1 Although the initial versions of the new servers will support the
old-style clients, only a subset of the potential facilities provided
will be accessible.  In particular, inter-filestore redirection and
single-point authorisation could not easily be implemented under the
old-style system.
However, the standardisation of the (slow) ether
protocols will require a change in the Fred-machine system software in any
case, and at that time the new facilities will become available.  In
addition, it will be possible to configure three different type of client
systems: discless clients which rely on network servers; clients with a
local disc and no network access (a stand-alone demonstration Fred-machine
has been suggested); and clients with both a local disc and access to
network severs (these latter might or might not choose to export access to
their local disc, using the same software as the dedicated servers).