Introducing Network File System Version 4 on HP-UX 11i v3

8
Figure 6. OPEN opcode request
On line 12, the OPEN opcode appears. A parameter of the OPEN opcode is the client identifier (line
16). As previously mentioned, the client identifier is required to identify the client performing the
open. Note how the client identifier on line 16 matches the identifier that was returned to the client as
part of the SETCLIENTID opcode in Figure 4, line 11.
Note the share_access and share_deny fields in the OPEN opcode on lines 14 and 15. These fields
are used to support share lock semantics, which are familiar in the Windows environment and are
now available in NFSv4. Share lock support improves Windows and UNIX interoperability by
enabling Windows applications that rely on share locks to work with HP-UX 11i v3 NFSv4 servers.
Share locks enable clients open access to a file while at the same time denying future open accesses
to other client processes. If the server is unable to acquire the requested locks or deny future lock
requests, the open fails. For example, if a client wants to prevent updates to a file while the client
reads the file, then the client would open the file with a share read lock and a share deny write lock.
If no other clients are writing the file, then the open succeeds. The share locks are in effect until the
client closes the file. Subsequent attempts by other clients to open the file with share write access fail
until the client closes the file.