uint64 typedef unsigned hyper uint64; int64 typedef hyper int64; uint32 typedef unsigned long uint32; int32 typedef long int32;
These types are new for the NLM version 4 protocol. They are the same as in the NFS version 3 protocol.
nlm4_stats enum nlm4_stats { NLM4_GRANTED = 0, NLM4_DENIED = 1, NLM4_DENIED_NOLOCKS = 2, NLM4_BLOCKED = 3, NLM4_DENIED_GRACE_PERIOD = 4, NLM4_DEADLCK = 5, NLM4_ROFS = 6, NLM4_STALE_FH = 7, NLM4_FBIG = 8, NLM4_FAILED = 9 };
Nlm4_stats indicates the success or failure of a call. This version contains several new error codes, so that clients can provide more precise failure information to applications.
The call completed successfully.
The call failed. For attempts to set a lock, this status implies that if the client retries the call later, it may succeed.
The call failed because the server could not allocate the necessary resources.
Indicates that a blocking request cannot be granted immediately. The server will issue an NLMPROC4_GRANTED callback to the client when the lock is granted.
The call failed because the server is reestablishing old locks after a reboot and is not yet ready to resume normal service.
The request could not be granted and blocking would cause a deadlock.
The call failed because the remote file system is read-only. For example, some server implementations might not support exclusive locks on read-only file systems.
The call failed because it uses an invalid file handle. This can happen if the file has been removed or if access to the file has been revoked on the server.
The call failed because it specified a length or offset that exceeds the range supported by the server.
The call failed for some reason not already listed. The client should take this status as a strong hint not to retry the request.
nlm4_holder struct nlm4_holder { bool exclusive; int32 svid; netobj oh; uint64 l_offset; uint64 l_len; };
This structure indicates the holder of a lock. The exclusive field tells whether the holder has an exclusive lock or a shared lock. The svid field identifies the process that is holding the lock. The oh field is an opaque object that identifies the host or process that is holding the lock. The l_len and l_offset fields identify the region that is locked. The only difference between the NLM version 3 protocol and the NLM version 4 protocol is that in the NLM version 3 protocol, the l_len and l_offset fields are 32 bits wide, while they are 64 bits wide in the NLM version 4 protocol.
nlm4_lock struct nlm4_lock { string caller_name<LM_MAXSTRLEN>; netobj fh; netobj oh; int32 svid; uint64 l_offset; uint64 l_len; };
This structure describes a lock request. The caller_name field identifies the host that is making the request. The fh field identifies the file to lock. The oh field is an opaque object that identifies the host or process that is making the request, and the svid field identifies the process that is making the request. The l_offset and l_len fields identify the region of the file that the lock controls. A l_len of 0 means "to end of file".
There are two differences between the NLM version 3 protocol and the NLM version 4 protocol versions of this structure. First, in the NLM version 3 protocol, the length and offset are 32 bits wide, while they are 64 bits wide in the NLM version 4 protocol. Second, in the NLM version 3 protocol, the file handle is a fixed-length NFS version 2 protocol file handle, which is encoded as a byte count followed by a byte array. In the NFS version 3 protocol, the file handle is already variable-length, so it is copied directly into the fh field. That is, the first four bytes of the fh field are the same as the byte count in an NFS version 3 protocol nfs_fh3. The rest of the fh field contains the byte array from the NFS version 3 protocol nfs_fh3.
nlm4_share struct nlm4_share { string caller_name<LM_MAXSTRLEN>; netobj fh; netobj oh; fsh4_mode mode; fsh4_access access; };
This structure is used to support DOS file sharing. The caller_name field identifies the host making the request. The fh field identifies the file to be operated on. The oh field is an opaque object that identifies the host or process that is making the request. The mode and access fields specify the file-sharing and access modes. The encoding of fh is a byte count, followed by the file handle byte array. See the description of nlm4_lock for more details.