Network Working Group B. Callaghan
`Request for Comments: 1813 B. Pawlowski
`Category: Informational P. Staubach
` Sun Microsystems, Inc.
` June 1995
`
` NFS Version 3 Protocol Specification
`
`Status of this Memo
`
` This memo provides information for the Internet community.
` This memo does not specify an Internet standard of any kind.
` Distribution of this memo is unlimited.
`
`IESG Note
`
` Internet Engineering Steering Group comment: please note that
` the IETF is not involved in creating or maintaining this
` specification. This is the significance of the specification
` not being on the standards track.
`
`Abstract
`
` This paper describes the NFS version 3 protocol. This paper is
` provided so that people can write compatible implementations.
`
`Table of Contents
`
` 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
` 1.1 Scope of the NFS version 3 protocol . . . . . . . . . . 4
` 1.2 Useful terms . . . . . . . . . . . . . . . . . . . . . . 5
` 1.3 Remote Procedure Call . . . . . . . . . . . . . . . . . 5
` 1.4 External Data Representation . . . . . . . . . . . . . . 5
` 1.5 Authentication and Permission Checking . . . . . . . . . 7
` 1.6 Philosophy . . . . . . . . . . . . . . . . . . . . . . . 8
` 1.7 Changes from the NFS version 2 protocol . . . . . . . . 11
` 2. RPC Information . . . . . . . . . . . . . . . . . . . . . 14
` 2.1 Authentication . . . . . . . . . . . . . . . . . . . . . 14
` 2.2 Constants . . . . . . . . . . . . . . . . . . . . . . . 14
` 2.3 Transport address . . . . . . . . . . . . . . . . . . . 14
` 2.4 Sizes . . . . . . . . . . . . . . . . . . . . . . . . . 14
` 2.5 Basic Data Types . . . . . . . . . . . . . . . . . . . . 15
` 2.6 Defined Error Numbers . . . . . . . . . . . . . . . . . 17
` 3. Server Procedures . . . . . . . . . . . . . . . . . . . . 27
` 3.1 General comments on attributes . . . . . . . . . . . . . 29
` 3.2 General comments on filenames . . . . . . . . . . . . . 30
` 3.3.0 NULL: Do nothing . . . . . . . . . . . . . . . . . . . . 31
`
`Callaghan, el al Informational [Page 1]
`
`Petitioner Microsoft Corporation - Ex. 1042, p. 1
`
`

`

`
`RFC 1813 NFS Version 3 Protocol June 1995
`
` 3.3.1 GETATTR: Get file attributes . . . . . . . . . . . . . . 32
` 3.3.2 SETATTR: Set file attributes . . . . . . . . . . . . . . 33
` 3.3.3 LOOKUP: Lookup filename . . . . . . . . . . . . . . . . 37
` 3.3.4 ACCESS: Check access permission . . . . . . . . . . . . 40
` 3.3.5 READLINK: Read from symbolic link . . . . . . . . . . . 44
` 3.3.6 READ: Read from file . . . . . . . . . . . . . . . . . . 46
` 3.3.7 WRITE: Write to file . . . . . . . . . . . . . . . . . . 49
` 3.3.8 CREATE: Create a file . . . . . . . . . . . . . . . . . 54
` 3.3.9 MKDIR: Create a directory . . . . . . . . . . . . . . . 58
` 3.3.10 SYMLINK: Create a symbolic link . . . . . . . . . . . . 61
` 3.3.11 MKNOD: Create a special device . . . . . . . . . . . . . 63
` 3.3.12 REMOVE: Remove a file . . . . . . . . . . . . . . . . . 67
` 3.3.13 RMDIR: Remove a directory . . . . . . . . . . . . . . . 69
` 3.3.14 RENAME: Rename a file or directory . . . . . . . . . . . 71
` 3.3.15 LINK: Create link to an object . . . . . . . . . . . . . 74
` 3.3.16 READDIR: Read From directory . . . . . . . . . . . . . . 76
` 3.3.17 READDIRPLUS: Extended read from directory . . . . . . . 80
` 3.3.18 FSSTAT: Get dynamic file system information . . . . . . 84
` 3.3.19 FSINFO: Get static file system information . . . . . . . 86
` 3.3.20 PATHCONF: Retrieve POSIX information . . . . . . . . . . 90
` 3.3.21 COMMIT: Commit cached data on a server to stable storage 92
` 4. Implementation issues . . . . . . . . . . . . . . . . . . 96
` 4.1 Multiple version support . . . . . . . . . . . . . . . . 96
` 4.2 Server/client relationship . . . . . . . . . . . . . . . 96
` 4.3 Path name interpretation . . . . . . . . . . . . . . . . 97
` 4.4 Permission issues . . . . . . . . . . . . . . . . . . . 98
` 4.5 Duplicate request cache . . . . . . . . . . . . . . . . 99
` 4.6 File name component handling . . . . . . . . . . . . . . 101
` 4.7 Synchronous modifying operations . . . . . . . . . . . . 101
` 4.8 Stable storage . . . . . . . . . . . . . . . . . . . . . 101
` 4.9 Lookups and name resolution . . . . . . . . . . . . . . 102
` 4.10 Adaptive retransmission . . . . . . . . . . . . . . . . 102
` 4.11 Caching policies . . . . . . . . . . . . . . . . . . . . 102
` 4.12 Stable versus unstable writes. . . . . . . . . . . . . . 103
` 4.13 32 bit clients/servers and 64 bit clients/servers. . . . 104
` 5. Appendix I: Mount protocol . . . . . . . . . . . . . . . . 106
` 5.1 RPC Information . . . . . . . . . . . . . . . . . . . . 106
` 5.1.1 Authentication . . . . . . . . . . . . . . . . . . . . 106
` 5.1.2 Constants . . . . . . . . . . . . . . . . . . . . . . 106
` 5.1.3 Transport address . . . . . . . . . . . . . . . . . . 106
` 5.1.4 Sizes . . . . . . . . . . . . . . . . . . . . . . . . 106
` 5.1.5 Basic Data Types . . . . . . . . . . . . . . . . . . . 106
` 5.2 Server Procedures . . . . . . . . . . . . . . . . . . . 107
` 5.2.0 NULL: Do nothing . . . . . . . . . . . . . . . . . . . 108
` 5.2.1 MNT: Add mount entry . . . . . . . . . . . . . . . . . 109
` 5.2.2 DUMP: Return mount entries . . . . . . . . . . . . . . 110
` 5.2.3 UMNT: Remove mount entry . . . . . . . . . . . . . . . 111
` 5.2.4 UMNTALL: Remove all mount entries . . . . . . . . . . 112
`
`Callaghan, el al Informational [Page 2]
`
`Petitioner Microsoft Corporation - Ex. 1042, p. 2
`
`

`

`
`RFC 1813 NFS Version 3 Protocol June 1995
`
` 5.2.5 EXPORT: Return export list . . . . . . . . . . . . . . 113
` 6. Appendix II: Lock manager protocol . . . . . . . . . . . . 114
` 6.1 RPC Information . . . . . . . . . . . . . . . . . . . . 114
` 6.1.1 Authentication . . . . . . . . . . . . . . . . . . . . 114
` 6.1.2 Constants . . . . . . . . . . . . . . . . . . . . . . 114
` 6.1.3 Transport Address . . . . . . . . . . . . . . . . . . 115
` 6.1.4 Basic Data Types . . . . . . . . . . . . . . . . . . . 115
` 6.2 NLM Procedures . . . . . . . . . . . . . . . . . . . . . 118
` 6.2.0 NULL: Do nothing . . . . . . . . . . . . . . . . . . . 120
` 6.3 Implementation issues . . . . . . . . . . . . . . . . . 120
` 6.3.1 64-bit offsets and lengths . . . . . . . . . . . . . . 120
` 6.3.2 File handles . . . . . . . . . . . . . . . . . . . . . 120
` 7. Appendix III: Bibliography . . . . . . . . . . . . . . . . 122
` 8. Security Considerations . . . . . . . . . . . . . . . . . 125
` 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 125
` 10. Authors’ Addresses . . . . . . . . . . . . . . . . . . . . 126
`
`1. Introduction
`
` Sun’s NFS protocol provides transparent remote access to shared
` file systems across networks. The NFS protocol is designed to be
` machine, operating system, network architecture, and transport
` protocol independent. This independence is achieved through the
` use of Remote Procedure Call (RPC) primitives built on top of an
` eXternal Data Representation (XDR). Implementations of the NFS
` version 2 protocol exist for a variety of machines, from personal
` computers to supercomputers. The initial version of the NFS
` protocol is specified in the Network File System Protocol
` Specification [RFC1094]. A description of the initial
` implementation can be found in [Sandberg].
`
` The supporting MOUNT protocol performs the operating
` system-specific functions that allow clients to attach remote
` directory trees to a point within the local file system. The
` mount process also allows the server to grant remote access
` privileges to a restricted set of clients via export control.
`
` The Lock Manager provides support for file locking when used in
` the NFS environment. The Network Lock Manager (NLM) protocol
` isolates the inherently stateful aspects of file locking into a
` separate protocol.
`
` A complete description of the above protocols and their
` implementation is to be found in [X/OpenNFS].
`
` The purpose of this document is to:
`
`Callaghan, el al Informational [Page 3]
`
`Petitioner Microsoft Corporation - Ex. 1042, p. 3
`
`

`

`
`RFC 1813 NFS Version 3 Protocol June 1995
`
` o Specify the NFS version 3 protocol.
`
` o Describe semantics of the protocol through annotation
` and description of intended implementation.
`
` o Specify the MOUNT version 3 protocol.
`
` o Briefly describe the changes between the NLM version 3
` protocol and the NLM version 4 protocol.
`
` The normative text is the description of the RPC procedures and
` arguments and results, which defines the over-the-wire protocol,
` and the semantics of those procedures. The material describing
` implementation practice aids the understanding of the protocol
` specification and describes some possible implementation issues
` and solutions. It is not possible to describe all implementations
` and the UNIX operating system implementation of the NFS version 3
` protocol is most often used to provide examples. Given that, the
` implementation discussion does not bear the authority of the
` description of the over-the-wire protocol itself.
`
`1.1 Scope of the NFS version 3 protocol
`
` This revision of the NFS protocol addresses new requirements.
` The need to support larger files and file systems has prompted
` extensions to allow 64 bit file sizes and offsets. The revision
` enhances security by adding support for an access check to be
` done on the server. Performance modifications are of three
` types:
`
` 1. The number of over-the-wire packets for a given
` set of file operations is reduced by returning file
` attributes on every operation, thus decreasing the number
` of calls to get modified attributes.
`
` 2. The write throughput bottleneck caused by the synchronous
` definition of write in the NFS version 2 protocol has been
` addressed by adding support so that the NFS server can do
` unsafe writes. Unsafe writes are writes which have not
` been committed to stable storage before the operation
` returns. This specification defines a method for
` committing these unsafe writes to stable storage in a
` reliable way.
`
` 3. Limitations on transfer sizes have been relaxed.
`
` The ability to support multiple versions of a protocol in RPC
` will allow implementors of the NFS version 3 protocol to define
`
`Callaghan, el al Informational [Page 4]
`
`Petitioner Microsoft Corporation - Ex. 1042, p. 4
`
`

`

`
`RFC 1813 NFS Version 3 Protocol June 1995
`
` clients and servers that provide backwards compatibility with
` the existing installed base of NFS version 2 protocol
` implementations.
`
` The extensions described here represent an evolution of the
` existing NFS protocol and most of the design features of the
` NFS protocol described in [Sandberg] persist. See Changes
` from the NFS version 2 protocol on page 11 for a more
` detailed summary of the changes introduced by this revision.
`
`1.2 Useful terms
`
` In this specification, a "server" is a machine that provides
` resources to the network; a "client" is a machine that accesses
` resources over the network; a "user" is a person logged in on a
` client; an "application" is a program that executes on a client.
`
`1.3 Remote Procedure Call
`
` The Sun Remote Procedure Call specification provides a
` procedure-oriented interface to remote services. Each server
` supplies a program, which is a set of procedures. The NFS
` service is one such program. The combination of host address,
` program number, version number, and procedure number specify one
` remote service procedure. Servers can support multiple versions
` of a program by using different protocol version numbers.
`
` The NFS protocol was designed to not require any specific level
` of reliability from its lower levels so it could potentially be
` used on many underlying transport protocols. The NFS service is
` based on RPC which provides the abstraction above lower level
` network and transport protocols.
`
` The rest of this document assumes the NFS environment is
` implemented on top of Sun RPC, which is specified in [RFC1057].
` A complete discussion is found in [Corbin].
`
`1.4 External Data Representation
`
` The eXternal Data Representation (XDR) specification provides a
` standard way of representing a set of data types on a network.
` This solves the problem of different byte orders, structure
` alignment, and data type representation on different,
` communicating machines.
`
` In this document, the RPC Data Description Language is used to
` specify the XDR format parameters and results to each of the RPC
` service procedures that an NFS server provides. The RPC Data
`
`Callaghan, el al Informational [Page 5]
`
`Petitioner Microsoft Corporation - Ex. 1042, p. 5
`
`

`

`
`RFC 1813 NFS Version 3 Protocol June 1995
`
` Description Language is similar to declarations in the C
` programming language. A few new constructs have been added.
` The notation:
`
` string name[SIZE];
` string data<DSIZE>;
`
` defines name, which is a fixed size block of SIZE bytes, and
` data, which is a variable sized block of up to DSIZE bytes. This
` notation indicates fixed-length arrays and arrays with a
` variable number of elements up to a fixed maximum. A
` variable-length definition with no size specified means there is
` no maximum size for the field.
`
` The discriminated union definition:
`
` union example switch (enum status) {
` case OK:
` struct {
` filename file1;
` filename file2;
` integer count;
` }
` case ERROR:
` struct {
` errstat error;
` integer errno;
` }
` default:
` void;
` }
`
` defines a structure where the first thing over the network is an
` enumeration type called status. If the value of status is OK,
` the next thing on the network will be the structure containing
` file1, file2, and count. Else, if the value of status is ERROR,
` the next thing on the network will be a structure containing
` error and errno. If the value of status is neither OK nor
` ERROR, then there is no more data in the structure.
`
` The XDR type, hyper, is an 8 byte (64 bit) quantity. It is used
` in the same way as the integer type. For example:
`
` hyper foo;
` unsigned hyper bar;
`
` foo is an 8 byte signed value, while bar is an 8 byte unsigned
` value.
`
`Callaghan, el al Informational [Page 6]
`
`Petitioner Microsoft Corporation - Ex. 1042, p. 6
`
`

`

`
`RFC 1813 NFS Version 3 Protocol June 1995
`
` Although RPC/XDR compilers exist to generate client and server
` stubs from RPC Data Description Language input, NFS
` implementations do not require their use. Any software that
` provides equivalent encoding and decoding to the canonical
` network order of data defined by XDR can be used to interoperate
` with other NFS implementations.
`
` XDR is described in [RFC1014].
`
`1.5 Authentication and Permission Checking
`
` The RPC protocol includes a slot for authentication parameters
` on every call. The contents of the authentication parameters are
` determined by the type of authentication used by the server and
` client. A server may support several different flavors of
` authentication at once. The AUTH_NONE flavor provides null
` authentication, that is, no authentication information is
` passed. The AUTH_UNIX flavor provides UNIX-style user ID, group
` ID, and groups with each call. The AUTH_DES flavor provides
` DES-encrypted authentication parameters based on a network-wide
` name, with session keys exchanged via a public key scheme. The
` AUTH_KERB flavor provides DES encrypted authentication
` parameters based on a network-wide name with session keys
` exchanged via Kerberos secret keys.
`
` The NFS server checks permissions by taking the credentials from
` the RPC authentication information in each remote request. For
` example, using the AUTH_UNIX flavor of authentication, the
` server gets the user’s effective user ID, effective group ID and
` groups on each call, and uses them to check access. Using user
` ids and group ids implies that the client and server either
` share the same ID list or do local user and group ID mapping.
` Servers and clients must agree on the mapping from user to uid
` and from group to gid, for those sites that do not implement a
` consistent user ID and group ID space. In practice, such mapping
` is typically performed on the server, following a static mapping
` scheme or a mapping established by the user from a client at
` mount time.
`
` The AUTH_DES and AUTH_KERB style of authentication is based on a
` network-wide name. It provides greater security through the use
` of DES encryption and public keys in the case of AUTH_DES, and
` DES encryption and Kerberos secret keys (and tickets) in the
` AUTH_KERB case. Again, the server and client must agree on the
` identity of a particular name on the network, but the name to
` identity mapping is more operating system independent than the
` uid and gid mapping in AUTH_UNIX. Also, because the
` authentication parameters are encrypted, a malicious user must
`
`Callaghan, el al Informational [Page 7]
`
`Petitioner Microsoft Corporation - Ex. 1042, p. 7
`
`

`

`
`RFC 1813 NFS Version 3 Protocol June 1995
`
` know another users network password or private key to masquerade
` as that user. Similarly, the server returns a verifier that is
` also encrypted so that masquerading as a server requires knowing
` a network password.
`
` The NULL procedure typically requires no authentication.
`
`1.6 Philosophy
`
` This specification defines the NFS version 3 protocol, that is
` the over-the-wire protocol by which a client accesses a server.
` The protocol provides a well-defined interface to a server’s
` file resources. A client or server implements the protocol and
` provides a mapping of the local file system semantics and
` actions into those defined in the NFS version 3 protocol.
` Implementations may differ to varying degrees, depending on the
` extent to which a given environment can support all the
` operations and semantics defined in the NFS version 3 protocol.
` Although implementations exist and are used to illustrate
` various aspects of the NFS version 3 protocol, the protocol
` specification itself is the final description of how clients
` access server resources.
`
` Because the NFS version 3 protocol is designed to be
` operating-system independent, it does not necessarily match the
` semantics of any existing system. Server implementations are
` expected to make a best effort at supporting the protocol. If a
` server cannot support a particular protocol procedure, it may
` return the error, NFS3ERR_NOTSUP, that indicates that the
` operation is not supported. For example, many operating systems
` do not support the notion of a hard link. A server that cannot
` support hard links should return NFS3ERR_NOTSUP in response to a
` LINK request. FSINFO describes the most commonly unsupported
` procedures in the properties bit map. Alternatively, a server
` may not natively support a given operation, but can emulate it
` in the NFS version 3 protocol implementation to provide greater
` functionality.
`
` In some cases, a server can support most of the semantics
` described by the protocol but not all. For example, the ctime
` field in the fattr structure gives the time that a file’s
` attributes were last modified. Many systems do not keep this
` information. In this case, rather than not support the GETATTR
` operation, a server could simulate it by returning the last
` modified time in place of ctime. Servers must be careful when
` simulating attribute information because of possible side
` effects on clients. For example, many clients use file
` modification times as a basis for their cache consistency
`
`Callaghan, el al Informational [Page 8]
`
`Petitioner Microsoft Corporation - Ex. 1042, p. 8
`
`

`

`
`RFC 1813 NFS Version 3 Protocol June 1995
`
` scheme.
`
` NFS servers are dumb and NFS clients are smart. It is the
` clients that do the work required to convert the generalized
` file access that servers provide into a file access method that
` is useful to applications and users. In the LINK example given
` above, a UNIX client that received an NFS3ERR_NOTSUP error from
` a server would do the recovery necessary to either make it look
` to the application like the link request had succeeded or return
` a reasonable error. In general, it is the burden of the client
` to recover.
`
` The NFS version 3 protocol assumes a stateless server
` implementation. Statelessness means that the server does not
` need to maintain state about any of its clients in order to
` function correctly. Stateless servers have a distinct advantage
` over stateful servers in the event of a crash. With stateless
` servers, a client need only retry a request until the server
` responds; the client does not even need to know that the server
` has crashed. See additional comments in Duplicate request cache
` on page 99.
`
` For a server to be useful, it holds nonvolatile state: data
` stored in the file system. Design assumptions in the NFS version
` 3 protocol regarding flushing of modified data to stable storage
` reduce the number of failure modes in which data loss can occur.
` In this way, NFS version 3 protocol implementations can tolerate
` transient failures, including transient failures of the network.
` In general, server implementations of the NFS version 3 protocol
` cannot tolerate a non-transient failure of the stable storage
` itself. However, there exist fault tolerant implementations
` which attempt to address such problems.
`
` That is not to say that an NFS version 3 protocol server can’t
` maintain noncritical state. In many cases, servers will maintain
` state (cache) about previous operations to increase performance.
` For example, a client READ request might trigger a read-ahead of
` the next block of the file into the server’s data cache in the
` anticipation that the client is doing a sequential read and the
` next client READ request will be satisfied from the server’s
` data cache instead of from the disk. Read-ahead on the server
` increases performance by overlapping server disk I/O with client
` requests. The important point here is that the read-ahead block
` is not necessary for correct server behavior. If the server
` crashes and loses its memory cache of read buffers, recovery is
` simple on reboot - clients will continue read operations
` retrieving data from the server disk.
`
`Callaghan, el al Informational [Page 9]
`
`Petitioner Microsoft Corporation - Ex. 1042, p. 9
`
`

`

`
`RFC 1813 NFS Version 3 Protocol June 1995
`
` Most data-modifying operations in the NFS protocol are
` synchronous. That is, when a data modifying procedure returns
` to the client, the client can assume that the operation has
` completed and any modified data associated with the request is
` now on stable storage. For example, a synchronous client WRITE
` request may cause the server to update data blocks, file system
` information blocks, and file attribute information - the latter
` information is usually referred to as metadata. When the WRITE
` operation completes, the client can assume that the write data
` is safe and discard it. This is a very important part of the
` stateless nature of the server. If the server did not flush
` dirty data to stable storage before returning to the client, the
` client would have no way of knowing when it was safe to discard
` modified data. The following data modifying procedures are
` synchronous: WRITE (with stable flag set to FILE_SYNC), CREATE,
` MKDIR, SYMLINK, MKNOD, REMOVE, RMDIR, RENAME, LINK, and COMMIT.
`
` The NFS version 3 protocol introduces safe asynchronous writes
` on the server, when the WRITE procedure is used in conjunction
` with the COMMIT procedure. The COMMIT procedure provides a way
` for the client to flush data from previous asynchronous WRITE
` requests on the server to stable storage and to detect whether
` it is necessary to retransmit the data. See the procedure
` descriptions of WRITE on page 49 and COMMIT on page 92.
`
` The LOOKUP procedure is used by the client to traverse
` multicomponent file names (pathnames). Each call to LOOKUP is
` used to resolve one segment of a pathname. There are two reasons
` for restricting LOOKUP to a single segment: it is hard to
` standardize a common format for hierarchical file names and the
` client and server may have different mappings of pathnames to
` file systems. This would imply that either the client must break
` the path name at file system attachment points, or the server
` must know about the client’s file system attachment points. In
` NFS version 3 protocol implementations, it is the client that
` constructs the hierarchical file name space using mounts to
` build a hierarchy. Support utilities, such as the Automounter,
` provide a way to manage a shared, consistent image of the file
` name space while still being driven by the client mount
` process.
`
` Clients can perform caching in varied manner. The general
` practice with the NFS version 2 protocol was to implement a
` time-based client-server cache consistency mechanism. It is
` expected NFS version 3 protocol implementations will use a
` similar mechanism. The NFS version 3 protocol has some explicit
` support, in the form of additional attribute information to
` eliminate explicit attribute checks. However, caching is not
`
`Callaghan, el al Informational [Page 10]
`
`Petitioner Microsoft Corporation - Ex. 1042, p. 10
`
`

`

`
`RFC 1813 NFS Version 3 Protocol June 1995
`
` required, nor is any caching policy defined by the protocol.
` Neither the NFS version 2 protocol nor the NFS version 3
` protocol provide a means of maintaining strict client-server
` consistency (and, by implication, consistency across client
` caches).
`
`1.7 Changes from the NFS Version 2 Protocol
`
` The ROOT and WRITECACHE procedures have been removed. A MKNOD
` procedure has been defined to allow the creation of special
` files, eliminating the overloading of CREATE. Caching on the
` client is not defined nor dictated by the NFS version 3
` protocol, but additional information and hints have been added
` to the protocol to allow clients that implement caching to
` manage their caches more effectively. Procedures that affect the
` attributes of a file or directory may now return the new
` attributes after the operation has completed to optimize out a
` subsequent GETATTR used in validating attribute caches. In
` addition, operations that modify the directory in which the
` target object resides return the old and new attributes of the
` directory to allow clients to implement more intelligent cache
` invalidation procedures. The ACCESS procedure provides access
` permission checking on the server, the FSSTAT procedure returns
` dynamic information about a file system, the FSINFO procedure
` returns static information about a file system and server, the
` READDIRPLUS procedure returns file handles and attributes in
` addition to directory entries, and the PATHCONF procedure
` returns POSIX pathconf information about a file.
`
` Below is a list of the important changes between the NFS version
` 2 protocol and the NFS version 3 protocol.
`
` File handle size
` The file handle has been increased to a variable-length
` array of 64 bytes maximum from a fixed array of 32
` bytes. This addresses some known requirements for a
` slightly larger file handle size. The file handle was
` converted from fixed length to variable length to
` reduce local storage and network bandwidth requirements
` for systems which do not utilize the full 64 bytes of
` length.
`
` Maximum data sizes
` The maximum size of a data transfer used in the READ
` and WRITE procedures is now set by values in the FSINFO
` return structure. In addition, preferred transfer sizes
` are returned by FSINFO. The protocol does not place any
` artificial limits on the maximum transfer sizes.
`
`Callaghan, el al Informational [Page 11]
`
`Petitioner Microsoft Corporation - Ex. 1042, p. 11
`
`

`

`
`RFC 1813 NFS Version 3 Protocol June 1995
`
` Filenames and pathnames are now specified as strings of
` variable length. The actual length restrictions are
` determined by the client and server implementations as
` appropriate. The protocol does not place any
` artificial limits on the length. The error,
` NFS3ERR_NAMETOOLONG, is provided to allow the server to
` return an indication to the client that it received a
` pathname that was too long for it to handle.
`
` Error return
` Error returns in some instances now return data (for
` example, attributes). nfsstat3 now defines the full set
` of errors that can be returned by a server. No other
` values are allowed.
`
` File type
` The file type now includes NF3CHR and NF3BLK for
` special files. Attributes for these types include
` subfields for UNIX major and minor devices numbers.
` NF3SOCK and NF3FIFO are now defined for sockets and
` fifos in the file system.
`
` File attributes
` The blocksize (the size in bytes of a block in the
` file) field has been removed. The mode field no longer
` contains file type information. The size and fileid
` fields have been widened to eight-byte unsigned
` integers from four-byte integers. Major and minor
` device information is now presented in a distinct
` structure. The blocks field name has been changed to
` used and now contains the total number of bytes used by
` the file. It is also an eight-byte unsigned integer.
`
` Set file attributes
` In the NFS version 2 protocol, the settable attributes
` were represented by a subset of the file attributes
` structure; the client indicated those attributes which
` were not to be modified by setting the corresponding
` field to -1, overloading some unsigned fields. The set
` file attributes structure now uses a discriminated
` union for each field to tell whether or how to set that
` field. The atime and mtime fields can be set to either
` the server’s current time or a time supplied by the
` client.
`
` LOOKUP
` The LOOKUP return structure now includes the attributes
` for the directory searched.
`
`Callaghan, el al Informational [Page 12]
`
`Petitioner Microsoft Corporation - Ex. 1042, p. 12
`
`

`

`
`RFC 1813 NFS Version 3 Protocol June 1995
`
` ACCESS
` An ACCESS procedure has been added to allow an explicit
` over-the-wire permissions check. This addresses known
` problems with the superuser ID mapping feature in many
` server implementations (where, due to mapping of root
` user, unexpected perm