rfc1813.txt

<VC++网络游戏建摸与实现>源代码

RFC 1813                 NFS Version 3 Protocol                June 1995


   NFS3ERR_NOTEMPTY

       An attempt was made to remove a directory that was not
       empty.

   NFS3ERR_DQUOT
       Resource (quota) hard limit exceeded. The user's resource
       limit on the server has been exceeded.

   NFS3ERR_STALE
       Invalid file handle. The file handle given in the
       arguments was invalid. The file referred to by that file
       handle no longer exists or access to it has been
       revoked.

   NFS3ERR_REMOTE
       Too many levels of remote in path. The file handle given
       in the arguments referred to a file on a non-local file
       system on the server.

   NFS3ERR_BADHANDLE
       Illegal NFS file handle. The file handle failed internal
       consistency checks.

   NFS3ERR_NOT_SYNC
       Update synchronization mismatch was detected during a
       SETATTR operation.

   NFS3ERR_BAD_COOKIE
       READDIR or READDIRPLUS cookie is stale.

   NFS3ERR_NOTSUPP
       Operation is not supported.

   NFS3ERR_TOOSMALL
       Buffer or request is too small.

   NFS3ERR_SERVERFAULT
       An error occurred on the server which does not map to any
       of the legal NFS version 3 protocol error values.  The
       client should translate this into an appropriate error.
       UNIX clients may choose to translate this to EIO.

   NFS3ERR_BADTYPE
       An attempt was made to create an object of a type not
       supported by the server.





Callaghan, el al             Informational                     [Page 19]

RFC 1813                 NFS Version 3 Protocol                June 1995


   NFS3ERR_JUKEBOX
       The server initiated the request, but was not able to
       complete it in a timely fashion. The client should wait
       and then try the request with a new RPC transaction ID.
       For example, this error should be returned from a server
       that supports hierarchical storage and receives a request
       to process a file that has been migrated. In this case,
       the server should start the immigration process and
       respond to client with this error.

   ftype3

      enum ftype3 {
         NF3REG    = 1,
         NF3DIR    = 2,
         NF3BLK    = 3,
         NF3CHR    = 4,
         NF3LNK    = 5,
         NF3SOCK   = 6,
         NF3FIFO   = 7
      };

   The enumeration, ftype3, gives the type of a file. The type,
   NF3REG, is a regular file, NF3DIR is a directory, NF3BLK is a
   block special device file, NF3CHR is a character special device
   file, NF3LNK is a symbolic link, NF3SOCK is a socket, and
   NF3FIFO is a named pipe. Note that the precise enum encoding
   must be followed.

   specdata3

      struct specdata3 {
           uint32     specdata1;
           uint32     specdata2;
      };

   The interpretation of the two words depends on the type of file
   system object. For a block special (NF3BLK) or character special
   (NF3CHR) file, specdata1 and specdata2 are the major and minor
   device numbers, respectively.  (This is obviously a
   UNIX-specific interpretation.) For all other file types, these
   two elements should either be set to 0 or the values should be
   agreed upon by the client and server. If the client and server
   do not agree upon the values, the client should treat these
   fields as if they are set to 0. This data field is returned as
   part of the fattr3 structure and so is available from all
   replies returning attributes. Since these fields are otherwise
   unused for objects which are not devices, out of band



Callaghan, el al             Informational                     [Page 20]

RFC 1813                 NFS Version 3 Protocol                June 1995


   information can be passed from the server to the client.
   However, once again, both the server and the client must agree
   on the values passed.

   nfs_fh3

      struct nfs_fh3 {
         opaque       data<NFS3_FHSIZE>;
      };

   The nfs_fh3 is the variable-length opaque object returned by the
   server on LOOKUP, CREATE, SYMLINK, MKNOD, LINK, or READDIRPLUS
   operations, which is used by the client on subsequent operations
   to reference the file. The file handle contains all the
   information the server needs to distinguish an individual file.
   To the client, the file handle is opaque. The client stores file
   handles for use in a later request and can compare two file
   handles from the same server for equality by doing a
   byte-by-byte comparison, but cannot otherwise interpret the
   contents of file handles. If two file handles from the same
   server are equal, they must refer to the same file, but if they
   are not equal, no conclusions can be drawn. Servers should try
   to maintain a one-to-one correspondence between file handles and
   files, but this is not required. Clients should use file handle
   comparisons only to improve performance, not for correct
   behavior.

   Servers can revoke the access provided by a file handle at any
   time.  If the file handle passed in a call refers to a file
   system object that no longer exists on the server or access for
   that file handle has been revoked, the error, NFS3ERR_STALE,
   should be returned.

   nfstime3

      struct nfstime3 {
         uint32   seconds;
         uint32   nseconds;
      };

   The nfstime3 structure gives the number of seconds and
   nanoseconds since midnight January 1, 1970 Greenwich Mean Time.
   It is used to pass time and date information. The times
   associated with files are all server times except in the case of
   a SETATTR operation where the client can explicitly set the file
   time. A server converts to and from local time when processing
   time values, preserving as much accuracy as possible. If the
   precision of timestamps stored for a file is less than that



Callaghan, el al             Informational                     [Page 21]

RFC 1813                 NFS Version 3 Protocol                June 1995


   defined by NFS version 3 protocol, loss of precision can occur.
   An adjunct time maintenance protocol is recommended to reduce
   client and server time skew.

   fattr3

      struct fattr3 {
         ftype3     type;
         mode3      mode;
         uint32     nlink;
         uid3       uid;
         gid3       gid;
         size3      size;
         size3      used;
         specdata3  rdev;
         uint64     fsid;
         fileid3    fileid;
         nfstime3   atime;
         nfstime3   mtime;
         nfstime3   ctime;
      };

   This structure defines the attributes of a file system object.
   It is returned by most operations on an object; in the case of
   operations that affect two objects (for example, a MKDIR that
   modifies the target directory attributes and defines new
   attributes for the newly created directory), the attributes for
   both may be returned. In some cases, the attributes are returned
   in the structure, wcc_data, which is defined below; in other
   cases the attributes are returned alone.  The main changes from
   the NFS version 2 protocol are that many of the fields have been
   widened and the major/minor device information is now presented
   in a distinct structure rather than being packed into a word.

   The fattr3 structure contains the basic attributes of a file.
   All servers should support this set of attributes even if they
   have to simulate some of the fields. Type is the type of the
   file. Mode is the protection mode bits. Nlink is the number of
   hard links to the file - that is, the number of different names
   for the same file. Uid is the user ID of the owner of the file.
   Gid is the group ID of the group of the file. Size is the size
   of the file in bytes. Used is the number of bytes of disk space
   that the file actually uses (which can be smaller than the size
   because the file may have holes or it may be larger due to
   fragmentation). Rdev describes the device file if the file type
   is NF3CHR or NF3BLK - see specdata3 on page 20. Fsid is the file
   system identifier for the file system. Fileid is a number which
   uniquely identifies the file within its file system (on UNIX



Callaghan, el al             Informational                     [Page 22]

RFC 1813                 NFS Version 3 Protocol                June 1995


   this would be the inumber). Atime is the time when the file data
   was last accessed. Mtime is the time when the file data was last
   modified.  Ctime is the time when the attributes of the file
   were last changed.  Writing to the file changes the ctime in
   addition to the mtime.

   The mode bits are defined as follows:

      0x00800 Set user ID on execution.
      0x00400 Set group ID on execution.
      0x00200 Save swapped text (not defined in POSIX).
      0x00100 Read permission for owner.
      0x00080 Write permission for owner.
      0x00040 Execute permission for owner on a file. Or lookup
              (search) permission for owner in directory.
      0x00020 Read permission for group.
      0x00010 Write permission for group.
      0x00008 Execute permission for group on a file. Or lookup
              (search) permission for group in directory.
      0x00004 Read permission for others.
      0x00002 Write permission for others.
      0x00001 Execute permission for others on a file. Or lookup
              (search) permission for others in directory.

   post_op_attr

      union post_op_attr switch (bool attributes_follow) {
      case TRUE:
         fattr3   attributes;
      case FALSE:
         void;
      };

   This structure is used for returning attributes in those
   operations that are not directly involved with manipulating
   attributes. One of the principles of this revision of the NFS
   protocol is to return the real value from the indicated
   operation and not an error from an incidental operation. The
   post_op_attr structure was designed to allow the server to
   recover from errors encountered while getting attributes.

   This appears to make returning attributes optional. However,
   server implementors are strongly encouraged to make best effort
   to return attributes whenever possible, even when returning an
   error.






Callaghan, el al             Informational                     [Page 23]

RFC 1813                 NFS Version 3 Protocol                June 1995


   wcc_attr

      struct wcc_attr {
         size3       size;
         nfstime3    mtime;
         nfstime3    ctime;
      };

   This is the subset of pre-operation attributes needed to better
   support the weak cache consistency semantics. Size is the file
   size in bytes of the object before the operation. Mtime is the
   time of last modification of the object before the operation.
   Ctime is the time of last change to the attributes of the object
   before the operation. See discussion in wcc_attr on page 24.

   The use of mtime by clients to detect changes to file system
   objects residing on a server is dependent on the granularity of
   the time base on the server.

   pre_op_attr

      union pre_op_attr switch (bool attributes_follow) {
      case TRUE:
           wcc_attr  attributes;
      case FALSE:
           void;
      };

   wcc_data

      struct wcc_data {
         pre_op_attr    before;
         post_op_attr   after;
      };

   When a client performs an operation that modifies the state of a
   file or directory on the server, it cannot immediately determine
   from the post-operation attributes whether the operation just
   performed was the only operation on the object since the last
   time the client received the attributes for the object. This is
   important, since if an intervening operation has changed the
   object, the client will need to invalidate any cached data for
   the object (except for the data that it just wrote).

   To deal with this, the notion of weak cache consistency data or
   wcc_data is introduced. A wcc_data structure consists of certain
   key fields from the object attributes before the operation,
   together with the object attributes after the operation. This



Callaghan, el al             Informational                     [Page 24]

RFC 1813                 NFS Version 3 Protocol                June 1995