{Begin SubSec File Servers}
{Title File Servers}
{Text

{index *PRIMARY* File servers}

A file server is a shared resource on a local communications network which provides large amounts of file storage.  Different file servers honor a variety of access protocols. Interlisp-D supports the following protocols:  PUP-FTP, PUP-Leaf, and NS Filing.  In addition, there are library packages available that support other communications protocols, such as {index *PRIMARY* TCP/IP}TCP/IP and RS232. 


With the exception of the RS232-based protocols, which exist only for file transfer, these network protocols are integrated into the Interlisp-D file system to allow files on a file server to be treated in much the same way files are accessed on local devices, such as the disk.  Thus, it is possible to call {fn OPENSTREAM} on the file {lisp {bracket ERIS}<LISP>FOO.DCOM;3} and read from it or write to it just as if the file had been on the local disk ({lisp {bracket DSK}<LISP>FOO.DCOM;3}), rather than on a remote server named {lisp ERIS}.  However, the protocols vary in how much control they give the workstation over file system operations.  Hence, some restrictions apply, as described in the following sections.


{Begin SubSec Pup File Server Protocols}
{Title Pup File Server Protocols}
{Text

There are two file server protocols in the family of Pup protocols: Leaf and FTP.  Some servers support both, while others support only one of them.  Interlisp-D uses whichever protocol is more appropriate for the requested operation.

Leaf is a random access protocol, so files opened using these protocols are {fn RANDACCESSP} ({PageRef fn RANDACCESSP}), and thus most normal i/o operations can be performed.  However, Leaf does not support directory enumeration.  Hence, {fn DIRECTORY} cannot be used on a Leaf file server unless the server also supports FTP.  In addition, Leaf does not supply easy access to a file's attributes.  {fn INFILEP} and {fn GETFILEINFO} have to open the file for input in order to obtain their information, and hence the file's read date will change, even though the semantics of these functions do not imply it.

FTP is a file transfer protocol that only permits sequential access to files.  However, most implementations of it are considerably more efficient than Leaf.  Interlisp-D uses FTP in preference to Leaf whenever the call to {fn OPENSTREAM} requests sequential access only.  In particular, the functions {fn SYSOUT} and {fn COPYFILE} open their files for sequential access.  If a file server supports FTP but for some reason it is undesirable for Lisp to use it, one can set the internal variable {indexx {Name FTPAVAILABLE} {Type Variable} {Text {lisp \FTPAVAILABLE}} }{index *PRIMARY* \FTPAVAILABLE Var}{var \FTPAVAILABLE} to {lisp NIL}.

The system normally maintains a Leaf connection to a host in the background.  This connection can be broken by calling {lisp (BREAKCONNECTION {arg HOST})}.{index BREAKCONNECTION FN}  Any subsequent reference to files on that host will reestablish the connection.   The principal use for this function arises when the user interrupts a file operation in such a way that the file server thinks the file is open but Lisp thinks it is closed (or not yet open).  As a result, the next time Lisp tries to open the file, it gets a file busy error.

}{End SubSec Pup File Server Protocols}

{Begin SubSec Xerox NS File Server Protocols}
{Title Xerox NS File Server Protocols}
{Text

Interlisp supports file access to Xerox 803x file servers, using the Filing Protocol built on Xerox Network Systems protocols.  Interlisp-D determines that a host is an NS File Server by the presence of a colon in its name, e.g., {lisp {bracket PHYLEX:}}.  The general format of NS fileserver device names is {lisp {bracket {arg SERVERNAME}:{arg DOMAIN}:{arg ORGANIZATION}}};  the device specification for an 8000-series product in general includes the ClearingHouse domain and organization.  If domain and organization are not supplied directly, then they are obtained from the defaults, which themselves are found by consulting the nearest ClearingHouse if the user has not defined them in an init file ({PageRef Var CH.DEFAULT.DOMAIN}).  However, note that the server name must still have a colon in it to distinguish it from other types of host names (e.g., Pup server names).

NS file servers in general permit arbitrary characters in file names.  The user should be cognizant of file name quoting conventions ({PageRef Tag QuotingFileNames}), and the fact that any file name presented as a litatom needs to have characters of significance to the reader, such as space, escaped with a {lisp %}.  Of course, one can always present the file name as a string, in which case only the quoting conventions are important.

NS file servers support a true hierarchical file system, where subdirectories are just another kind of file, which needs to be explicitly created.  In Interlisp, subdirectories are created automatically as needed:  A call to {fn OPENFILE} to create a file in a non-existent subdirectory automatically creates the subdirectory;  {lisp CONN} to a non-existent subdirectory asks the user whether to create the directory.  For those using Star software, a directory corresponds to a "File Drawer", while a subdirectory corresponds to a "File Folder".

Because of their hierarchical structure, NS directories can be enumerated to arbitrary levels.  The default is to enumerate all the files (the leaves of the tree), omitting the subdirectory nodes themselves.  This default can be changed by the following variable:

{vardef {name FILING.ENUMERATION.DEPTH}
{text
This variable is either a number, specifying the number of levels deep to enumerate, or {lisp T}, meaning enumerate to all levels.  In the former case, when the enumeration reaches the specified depth, only the subdirectory name rooted at that level is listed, and none of its descendants is listed.  When {var FILING.ENUMERATION.DEPTH} is {lisp T}, all files are listed, and no subdirectory names are listed.  {var FILING.ENUMERATION.DEPTH} is initially {lisp T}.

Independent of {var FILING.ENUMERATION.DEPTH}, a request to enumerate the top-level of a file server's hierarchy lists only the top level, i.e., assumes a depth of 1.  For example, {lisp (DIRECTORY '{bracket PHYLEX:})} lists exactly the top-level directories of the server {lisp PHYLEX:}.
}}


NS file servers do not currently support random access.  Therefore, {fn SETFILEPTR} of an NS file generally causes an error.  However, {fn GETFILEPTR} returns the correct character position for open files on NS file servers.  In addition, {fn SETFILEPTR} works in the special case where the file is open for input, and the file pointer is being set forward.  In this case, the intervening characters are automatically read.

Even while Interlisp has no file open on an NS Server, the system maintains a "session" with the server for a while in order to improve the speed of subsequent requests to the server.  While this session is open, it is possible for some nodes of the server's file system to appear "busy" or inaccessible to certain clients on other workstations (such as Star).  If this happens, the following function can be used to terminate any open sessions immediately:

{fndef {name BREAK.NSFILING.CONNECTION}{args HOST}
{text
Closes any open connections to NS file server {arg HOST}.
}}

}{End SubSec Xerox NS File Server Protocols}



{Begin SubSec Operating System Designations}
{Title Operating System Designations}
{Text

Some of the network server protocols are implemented on more than one kind of foreign host.  Such hosts vary in their conventions for logging in, naming files, representing end-of-line, etc.  In order for Interlisp to communicate gracefully with all these hosts, it is necessary that the variable {var NETWORKOSTYPES} be correctly set.

{VarDef {Name NETWORKOSTYPES}
{Text
An association-list that associates a host name with its operating system type.   Elements in this list are of the form {lisp ({arg HOSTNAME} . {arg TYPE})}, for example, {lisp (MAXC2 . TENEX)}.  The operating system types currently known to Lisp are {lisp TENEX}, {lisp TOPS20}, {lisp UNIX}, and {lisp VMS}.  The host names in this list should be the "canonical" host name, represented as an uppercase atom.  For Pup and NS hosts, the function {fn CANONICAL.HOSTNAME} (below) can be used to determine which of several aliases of a server is the canonical name.

{note expand documentation of NETWORKOSTYPES.  Explain exactly what lisp does for each type of network type}
}}

{Fndef {name CANONICAL.HOSTNAME}{args HOSTNAME}
{text
Returns the "canonical" name of the server {arg HOSTNAME}, or {lisp NIL} if {arg HOSTNAME} is not the name of a server.  
}}

}{End SubSec Operating System Designations}



{Begin SubSec Logging In}
{Title Logging In}
{Text

{index *PRIMARY* Logging into file servers}
{index *PRIMARY* Passwords}

Most file servers require a user name and password for access.  Interlisp-D maintains an ephemeral database of user names and passwords for each host accessed recently.  The database vanishes when {fn LOGOUT}, {fn SAVEVM}, {fn SYSOUT}, or {fn MAKESYS} is executed, so that the passwords remain secure from any subsequent user of the same virtual memory image.  Interlisp-D also maintains a notion of the "default" user name and password, which are generally those with which the user initially logs in (on the 1132, the default user name corresponds to that displayed in the Alto executive).

When a file server for which the system does not yet have an entry in its password database requests a name and password, the system first tries the default user name and password.  If the file server doesn't recognize that name/password, the system prompts the user for a name and password to use for that host.  It suggests a default name:

{lisp     {bracket ERIS} Login: Green}

which the user can accept by typing a carriage return, or replace the name by typing a new name or backspacing over it.  Following the name, the user is prompted for a password:

{lisp     {bracket ERIS} Login: Verdi (password)}

which is not echoed, terminated by another carriage return.  This information is stored in the password database so that the user is prompted only once, until the database is again cleared.

Interlisp-D also prompts for password information when a protection violation occurs on accessing a directory on certain kinds of servers that support password-protected directories.  Some such servers allow one to protect a file in a way that it is inaccessible to even its owner until the file's protection is changed; in such case, no password would help, and the system causes the normal {lisp PROTECTION VIOLATION}{index PROTECTION VIOLATION Error} error.

The user can abort a password interaction by typing the {lisp ERROR} interrupt, initially {index Control-E (Interrupt character)}Control-E.  This generally either causes a {lisp PROTECTION VIOLATION} error, if the password was requested in order to gain access to a protected file on an otherwise accessible server; or to act as though the server did not exist, in the case where the password was needed in order to gain {it any} access to the server.

The following functions are useful for altering the password database:

{FnDef {Name LOGIN} {Args HOSTNAME FLG DIRECTORY MSG}
{Text
Forces Interlisp-D to ask for the user name and password to be used when accessing host {arg HOSTNAME}.  Any previous login information for {arg HOSTNAME} is overriden.  If {arg HOSTNAME} is {lisp NIL}, it overrides login information for all hosts and resets the default user name and password to be those typed in by the user.  The special value {arg HOSTNAME} = {lisp NS::} is used to obtain the default user name and password for all logins for NS Servers. 

If {arg FLG} is the atom {lisp QUIET}, only prompts the user if there is no cached information for {arg HOSTNAME}.

If {arg DIRECTORY} is specified, it is the name of a directory on {arg HOSTNAME}.  In this case, the information requested is the "connect" password for that directory.  Connect passwords for any number of different directories on a host can be maintained.

If {arg MSG} is non-{lisp NIL}, it is a message (a string) to be printed before the name and password information is requested.

{fn LOGIN} returns the user name with which the user completed the login.
}}

{FnDef {Name SETPASSWORD} {Args HOST USER PASSWORD DIRECTORY}
{Text
Sets the values in the internal password database, exactly as if the strings {arg USER} and {arg PASSWORD} were typed in via {lisp (LOGIN {arg HOST} NIL {arg DIRECTORY})}.
}}

{FnDef {Name SETUSERNAME} {Args NAME}
{Text
Sets the default user name to {arg NAME}.
}}


{FnDef {FnName USERNAME} {FnArgs FLG STRPTR PRESERVECASE}
{Text
If {arg FLG}={lisp NIL}, returns the default user name.  This is the only value of {arg FLG} that is meaningful in Interlisp-D.

{fn USERNAME} returns the value as a string, unless {arg STRPTR} is {lisp T}, in which case {fn USERNAME} returns the value as an atom.  The name is returned in upper case, unless {arg PRESERVECASE} is true.
}}


}{End SubSec Logging In}


{Begin SubSec Abnormal Conditions}
{Title Abnormal Conditions}
{Text

If Interlisp-D tries to access a file and does not get a response from the file server in a reasonable period of time, it prints a message that the file server is not responding, and keeps trying.  If the file server has actually crashed, this may continue indefinitely.  A control-E or similar interrupt aborts out of this state.

If the file server crashes but is restarted before the user attempts to do anything, file operations will usually proceed normally, except for a brief pause while Interlisp-D tries to reestablish any connections it had open before the crash.  However, this is not always possible.  For example, when a file is open for sequential output and the server crashes, there is no way to recover the output already written, since it vanished with the crash.  In such cases, the system will cause an error such as {index Connection Lost Error}{lisp Connection Lost}.

{fn LOGOUT} closes any file server connections that are currently open.  On return, it attempts to reestablish connections for any files that were open before logging out.  If a file has disappeared or been modified, Interlisp-D reports this fact.  Files that were open for sequential access generally cannot be reopened after {fn LOGOUT}.

Interlisp supports simultaneous access to the same server from different processes and permits overlapping of Lisp computation with file server operations, allowing for improved performance.  However, as a corollary of this, a file is not closed the instant that {fn CLOSEF} returns;  Interlisp closes the file "in the background".  It is therefore very important that the user exits Interlisp via {lisp (LOGOUT)}, or {lisp (LOGOUT T)}, rather than boot the machine.

On rare occasions, the Ethernet may appear completely unresponsive, due to Interlisp having gotten into a bad state.  Typing {lisp (RESTART.ETHER)}{index RESTART.ETHER Fn} will reinitialize Lisp's Ethernet driver(s), just as when the Lisp system is started up following a {fn LOGOUT}, {fn SYSOUT}, etc (see {PageRef Fn RESTART.ETHER})


}{End SubSec Abnormal Conditions}




}{End SubSec File Servers}
&
&
?1(DEFAULTFONT 1 (GACHA 10) (GACHA 8) (TERMINAL 8))
?1(DEFAULTFONT 1 (GACHA 10) (GACHA 8) (TERMINAL 8))





”

Ñ

)"
ë
a
~

(
.'
q

¶

#






(




Ñ





!










¨





Ê




3



:



-


-&

P
2
m

0



z



,



,
P

V
'
²
2
¾

Í

Ä
G
6
Í
s



€
J
>¬
&*

:€
Ð



#

K
.

T

Ó

O

"



<

Izº