\&Read From Directory.IX "NFS server procedures" NFSPROC_READDIR() "" \fINFSPROC_READDIR()\fP.DSstruct readdirargs {	fhandle dir;            	nfscookie cookie;	unsigned count;         };struct entry {	unsigned fileid;	filename name;	nfscookie cookie;	entry *nextentry;};union readdirres switch (stat status) {	case NFS_OK:		struct {			entry *entries;			bool eof;		} readdirok;	default:		void;};readdirresNFSPROC_READDIR (readdirargs) = 16;.DE.KEReturns a variable number of  directory entries,  with a total sizeof up to "count" bytes, from the directory given  by "dir".  If thereturned  value of "status"  is .I NFS_OK ,then  it  is followed  by avariable  number  of "entry"s.    Each "entry" contains  a "fileid"which consists of a  unique number  to identify the  file within  afilesystem,  the  "name" of the  file, and a "cookie" which   is anopaque pointer to the next entry in  the  directory.  The cookie isused  in the next  .I READDIR call to get more  entries  starting at agiven point in  the directory.  The  special cookie zero (all  bitszero) can be used to get the entries starting  at the  beginning ofthe directory.  The "fileid" field should be the same number as the"fileid" in the the  attributes of the  file.  (See the.I "Basic Data Types"section.) The "eof" flag has a value of.I TRUE if there are no more entries in the directory..KS.NH 3\&Get Filesystem Attributes.IX "NFS server procedures" NFSPROC_STATFS() "" \fINFSPROC_STATFS()\fP.DSunion statfsres (stat status) {	case NFS_OK:		struct {			unsigned tsize; 			unsigned bsize; 			unsigned blocks;			unsigned bfree; 			unsigned bavail;		} info;	default:		void;};statfsresNFSPROC_STATFS(fhandle) = 17;.DE.KEIf the  reply "status"  is .I NFS_OK ,then the  reply "info" gives theattributes for the filesystem that contains file referred to by theinput fhandle.  The attribute fields contain the following values:.IP tsize:   The optimum transfer size of the server in bytes.  This isthe number  of bytes the server  would like to have in thedata part of READ and WRITE requests..IP bsize:   The block size in bytes of the filesystem..IP blocks:  The total number of "bsize" blocks on the filesystem..IP bfree:   The number of free "bsize" blocks on the filesystem..IP bavail:  The number of  "bsize" blocks  available to non-privileged users..LPNote: This call does not  work well if a  filesystem has  variablesize blocks..NH 1\&NFS Implementation Issues.IX NFS implementation.LPThe NFS protocol is designed to be operating system independent, butsince this version was designed in a UNIX environment, manyoperations have semantics similar to the operations of the UNIX filesystem.  This section discusses some of the implementation-specificsemantic issues..NH 2\&Server/Client Relationship.IX NFS "server/client relationship".LPThe NFS protocol is designed to allow servers to be as simple andgeneral as possible.  Sometimes the simplicity of the server can be aproblem, if the client wants to implement complicated filesystemsemantics..LPFor example, some operating systems allow removal of open files.  Aprocess can open a file and, while it is open, remove it from thedirectory.  The file can be read and written as long as the processkeeps it open, even though the file has no name in the filesystem.It is impossible for a stateless server to implement these semantics.The client can do some tricks such as renaming the file on remove,and only removing it on close.  We believe that the server providesenough functionality to implement most file system semantics on theclient..LPEvery NFS client can also potentially be a server, and remote andlocal mounted filesystems can be freely intermixed.  This leads tosome interesting problems when a client travels down the directorytree of a remote filesystem and reaches the mount point on the serverfor another remote filesystem.  Allowing the server to follow thesecond remote mount would require loop detection, server lookup, anduser revalidation.  Instead, we decided not to let clients cross aserver's mount point.  When a client does a LOOKUP on a directory onwhich the server has mounted a filesystem, the client sees theunderlying directory instead of the mounted directory.  A client cando remote mounts that match the server's mount points to maintain theserver's view..LP.NH 2\&Pathname Interpretation.IX NFS "pathname interpretation".LPThere are a few complications to the rule that pathnames are alwaysparsed on the client.  For example, symbolic links could havedifferent interpretations on different clients.  Another commonproblem for non-UNIX implementations is the special interpretation ofthe pathname ".."  to mean the parent of a given directory.  The nextrevision of the protocol uses an explicit flag to indicate the parentinstead..NH 2\&Permission Issues.IX NFS "permission issues".LPThe NFS protocol, strictly speaking, does not define the permissionchecking used  by servers.  However,  it is  expected that a serverwill do normal operating system permission checking using .I AUTH_UNIX style authentication as the basis of its protection mechanism.  Theserver gets the client's effective "uid", effective "gid", and groupson each call and uses them to check permission.  There are variousproblems with this method that can been resolved in interesting ways..LPUsing "uid" and "gid" implies that the client and server share thesame "uid" list.  Every server and client pair must have the samemapping from user to "uid" and from group to "gid".  Since everyclient can also be a server, this tends to imply that the wholenetwork shares the same "uid/gid" space..I AUTH_DES (and the  nextrevision of the NFS protocol) uses string names instead of numbers,but there are still complex problems to be solved..LPAnother problem arises due to the usually stateful open operation.Most operating systems check permission at open time, and then checkthat the file is open on each read and write request.  With statelessservers, the server has no idea that the file is open and must dopermission checking on each read and write call.  On a localfilesystem, a user can open a file and then change the permissions sothat no one is allowed to touch it, but will still be able to writeto the file because it is open.  On a remote filesystem, by contrast,the write would fail.  To get around this problem, the server'spermission checking algorithm should allow the owner of a file toaccess it regardless of the permission setting..LPA similar problem has to do with paging in from a file over thenetwork.  The operating system usually checks for execute permissionbefore opening a file for demand paging, and then reads blocks fromthe open file.  The file may not have read permission, but after itis opened it doesn't matter.  An NFS server can not tell thedifference between a normal file read and a demand page-in read.  Tomake this work, the server allows reading of files if the "uid" givenin the call has execute or read permission on the file..LPIn most operating systems, a particular user (on the user ID zero)has access to all files no matter what permission and ownership theyhave.  This "super-user" permission may not be allowed on the server,since anyone who can become super-user on their workstation couldgain access to all remote files.  The UNIX server by default mapsuser id 0 to -2 before doing its access checking.  This works exceptfor NFS root filesystems, where super-user access cannot be avoided..NH 2\&Setting RPC Parameters.IX NFS "setting RPC parameters".LPVarious file system parameters and options should be set at mounttime.  The mount protocol is described in the appendix below.  Forexample, "Soft" mounts as well as "Hard" mounts are usually bothprovided.  Soft mounted file systems return errors when RPCoperations fail (after a given number of optional retransmissions),while hard mounted file systems continue to retransmit forever.Clients and servers may need to keep caches of recent operations tohelp avoid problems with non-idempotent operations..NH 1\&Mount Protocol Definition.IX "mount protocol" "" "" "" PAGE MAJOR.sp 1.NH 2\&Introduction.IX "mount protocol" introduction.LPThe mount protocol is separate from, but related to, the NFSprotocol.  It provides operating system specific services to get theNFS off the ground -- looking up server path names, validating useridentity, and checking access permissions.  Clients use the mountprotocol to get the first file handle, which allows them entry into aremote filesystem..LPThe mount protocol is kept separate from the NFS protocol to make iteasy to plug in new access checking and validation methods withoutchanging the NFS server protocol..LPNotice that the protocol definition implies stateful servers becausethe server maintains a list of client's mount requests.  The mountlist information is not critical for the correct functioning ofeither the client or the server.  It is intended for advisory useonly, for example, to warn possible clients when a server is goingdown..LPVersion one of the mount protocol is used with version two of the NFSprotocol.  The only connecting point is the.I fhandle structure, which is the same for both protocols..NH 2\&RPC Information.IX "mount protocol"  "RPC information".IP \fIAuthentication\fPThe mount service uses .I AUTH_UNIX and .I AUTH_DES style authentication only..IP "\fITransport Protocols\fP"The mount service is currently supported on UDP/IP only..IP "\fIPort Number\fP"Consult the server's portmapper, described in the chapter.I "Remote Procedure Calls: Protocol Specification",to  find  the  port number on which the mount service is registered..NH 2\&Sizes of XDR Structures.IX "mount protocol" "XDR structure sizes".LPThese  are  the sizes,   given  in  decimal   bytes, of various XDRstructures used in the protocol:.DS/* \fIThe maximum number of bytes in a pathname argument\fP */const MNTPATHLEN = 1024;/* \fIThe maximum number of bytes in a name argument\fP */const MNTNAMLEN = 255;/* \fIThe size in bytes of the opaque file handle\fP */const FHSIZE = 32;.DE.NH 2\&Basic Data Types.IX "mount protocol" "basic data types".IX "mount data types".LPThis section presents the data  types used by  the  mount protocol.In many cases they are similar to the types used in NFS..KS.NH 3\&fhandle.IX "mount data types" fhandle "" \fIfhandle\fP.DStypedef opaque fhandle[FHSIZE];.DE.KEThe type .I fhandle is the file handle that the server passes to theclient.  All file operations are done  using file handles  to referto a  file  or directory.   The  file handle  can  contain whateverinformation the server needs to distinguish an individual file..LPThis  is the  same as the "fhandle" XDR definition in version 2 ofthe NFS protocol;  see .I "Basic Data Types"in the definition of the NFS protocol, above..KS.NH 3\&fhstatus.IX "mount data types" fhstatus "" \fIfhstatus\fP.DSunion fhstatus switch (unsigned status) {	case 0:		fhandle directory;	default:		void;};.DE.KEThe type .I fhstatus is a union.  If a "status" of zero is returned,the  call completed   successfully, and  a  file handle   for   the"directory"  follows.  A  non-zero  status indicates  some  sort oferror.  In this case the status is a UNIX error number..KS.NH 3\&dirpath.IX "mount data types" dirpath "" \fIdirpath\fP.DStypedef string dirpath<MNTPATHLEN>;.DE.KEThe type .I dirpath is a server pathname of a directory..KS.NH 3\&name.IX "mount data types" name "" \fIname\fP.DStypedef string name<MNTNAMLEN>;.DE.KEThe type .I name is an arbitrary string used for various names..NH 2\&Server Procedures.IX "mount server procedures".LPThe following sections define the RPC procedures  supplied by amount server..ie t .DS.el .DS L.ft I/** Protocol description for the mount program*/.ft CWprogram MOUNTPROG {.ft I/** Version 1 of the mount protocol used with* version 2 of the NFS protocol.*/.ft CW	version MOUNTVERS {		void        MOUNTPROC_NULL(void)    = 0;		fhstatus    MOUNTPROC_MNT(dirpath)  = 1;		mountlist   MOUNTPROC_DUMP(void)    = 2;		void        MOUNTPROC_UMNT(dirpath) = 3;		void        MOUNTPROC_UMNTALL(void) = 4;		exportlist  MOUNTPROC_EXPORT(void)  = 5;	} = 1;} = 100005;.DE.KS.NH 3\&Do Nothing.IX "mount server procedures" MNTPROC_NULL() "" \fIMNTPROC_NULL()\fP.DSvoid MNTPROC_NULL(void) = 0;.DE.KEThis  procedure does no work.  It   is  made  available in all  RPCservices to allow server response testing and timing..KS.NH 3\&Add Mount Entry.IX "mount server procedures" MNTPROC_MNT() "" \fIMNTPROC_MNT()\fP.DSfhstatusMNTPROC_MNT(dirpath) = 1;.DE.KEIf the reply "status" is 0, then the reply "directory" contains thefile handle for the directory "dirname".  This file handle may beused in the NFS protocol.  This procedure also adds a new entry tothe mount list for this client mounting "dirname"..KS.NH 3\&Return Mount Entries.IX "mount server procedures" MNTPROC_DUMP() "" \fIMNTPROC_DUMP()\fP.DSstruct *mountlist {	name      hostname;	dirpath   directory;	mountlist nextentry;};mountlistMNTPROC_DUMP(void) = 2;.DE.KEReturns  the list of  remote mounted filesystems.   The "mountlist"contains one entry for each "hostname" and "directory" pair..KS.NH 3\&Remove Mount Entry.IX "mount server procedures" MNTPROC_UMNT() "" \fIMNTPROC_UMNT()\fP.DSvoidMNTPROC_UMNT(dirpath) = 3;.DE.KERemoves the mount list entry for the input "dirpath"..KS.NH 3\&Remove All Mount Entries.IX "mount server procedures" MNTPROC_UMNTALL() "" \fIMNTPROC_UMNTALL()\fP.DSvoidMNTPROC_UMNTALL(void) = 4;.DE.KERemoves all of the mount list entries for this client..KS.NH 3\&Return Export List.IX "mount server procedures" MNTPROC_EXPORT() "" \fIMNTPROC_EXPORT()\fP.DSstruct *groups {	name grname;	groups grnext;};struct *exportlist {	dirpath filesys;	groups groups;	exportlist next;};exportlistMNTPROC_EXPORT(void) = 5;.DE.KEReturns a variable number of export list entries.  Each entrycontains a filesystem name and a list of groups that are allowed toimport it.  The filesystem name is in "filesys", and the group nameis in the list "groups"..LPNote:  The exportlist should containmore information about the status of the filesystem, such as aread-only flag.