NFS Version version 4 Working Group                                  S. Shepler
INTERNET-DRAFT                                   Sun Microsystems, Inc.
Document: draft-ietf-nfsv4-rfc3010bis-01.txt draft-ietf-nfsv4-rfc3010bis-02.txt                   C. Beame
                                                       Hummingbird Ltd.
                                                           B. Callaghan
                                                 Sun Microsystems, Inc.
                                                              M. Eisler
                                                          Zambeel,
                                                Network Appliance, Inc.
                                                              D. Noveck
                                                Network Appliance, Inc.
                                                            D. Robinson
                                                 Sun Microsystems, Inc.
                                                             R. Thurlow
                                                 Sun Microsystems, Inc.
                                                              July
                                                            August 2002

                         NFS version 4 Protocol

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   NFS version 4 is a distributed file system filesystem protocol which owes
   heritage to NFS protocol versions 2 [RFC1094] and 3 [RFC1813].

Draft Specification      NFS version 4 Protocol                July              August 2002

   Unlike earlier versions, the NFS version 4 protocol supports
   traditional file access while integrating support for file locking
   and the mount protocol.  In addition, support for strong security
   (and its negotiation), compound operations, client caching, and
   internationalization have been added.  Of course, attention has been
   applied to making NFS version 4 operate well in an Internet
   environment.

Copyright

   Copyright (C) The Internet Society (2000-2002).  All Rights Reserved.

Key Words

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119. [RFC2119].

Draft Specification      NFS version 4 Protocol                July              August 2002

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
   1.1.  Inconsistencies of this Document with Section 18 . . . . . 7
   1.2.  Overview of NFS Version version 4 Features . . . . . . . . . . . . 7
   1.1.1. 8
   1.2.1.  RPC and Security . . . . . . . . . . . . . . . . . . . . 8
   1.1.2.
   1.2.2.  Procedure and Operation Structure  . . . . . . . . . . . 8
   1.1.3.  File System
   1.2.3.  Filesystem Model . . . . . . . . . . . . . . . . . . . . 9
   1.1.3.1.
   1.2.3.1.  Filehandle Types . . . . . . . . . . . . . . . . . . . 9
   1.1.3.2.
   1.2.3.2.  Attribute Types  . . . . . . . . . . . . . . . . . . . 9
   1.1.3.3.  File System  10
   1.2.3.3.  Filesystem Replication and Migration . . . . . . . .  10
   1.1.4.
   1.2.4.  OPEN and CLOSE . . . . . . . . . . . . . . . . . . . .  10
   1.1.5.  11
   1.2.5.  File locking . . . . . . . . . . . . . . . . . . . . .  10
   1.1.6.  11
   1.2.6.  Client Caching and Delegation  . . . . . . . . . . . .  11
   1.2.
   1.3.  General Definitions  . . . . . . . . . . . . . . . . . .  12
   2.  Protocol Data Types  . . . . . . . . . . . . . . . . . . .  14
   2.1.  Basic Data Types . . . . . . . . . . . . . . . . . . . .  14
   2.2.  Structured Data Types  . . . . . . . . . . . . . . . . .  15
   3.  RPC and Security Flavor  . . . . . . . . . . . . . . . . .  20  21
   3.1.  Ports and Transports . . . . . . . . . . . . . . . . . .  20  21
   3.1.1.  Client Retransmission Behavior . . . . . . . . . . . .  21
   3.2.  Security Flavors . . . . . . . . . . . . . . . . . . . .  20  22
   3.2.1.  Security mechanisms for NFS version 4  . . . . . . . .  20  22
   3.2.1.1.  Kerberos V5 as a security triple . . . . . . . . . . .  21  22
   3.2.1.2.  LIPKEY as a security triple  . . . . . . . . . . . .  21  23
   3.2.1.3.  SPKM-3 as a security triple  . . . . . . . . . . . .  22  24
   3.3.  Security Negotiation . . . . . . . . . . . . . . . . . .  23  24
   3.3.1.  Security Error  SECINFO  . . . . . . . . . . . . . . . . . . . .  23
   3.3.2.  SECINFO . . .  25
   3.3.2.  Security Error . . . . . . . . . . . . . . . . . . . .  23  25
   3.4.  Callback RPC Authentication  . . . . . . . . . . . . . .  23  25
   4.  Filehandles  . . . . . . . . . . . . . . . . . . . . . . .  26  28
   4.1.  Obtaining the First Filehandle . . . . . . . . . . . . .  26  28
   4.1.1.  Root Filehandle  . . . . . . . . . . . . . . . . . . .  26  28
   4.1.2.  Public Filehandle  . . . . . . . . . . . . . . . . . .  27  28
   4.2.  Filehandle Types . . . . . . . . . . . . . . . . . . . .  27  29
   4.2.1.  General Properties of a Filehandle . . . . . . . . . .  27  29
   4.2.2.  Persistent Filehandle  . . . . . . . . . . . . . . . .  28  30
   4.2.3.  Volatile Filehandle  . . . . . . . . . . . . . . . . .  28  30
   4.2.4.  One Method of Constructing a Volatile Filehandle . . .  30  31
   4.3.  Client Recovery from Filehandle Expiration . . . . . . .  30  32
   5.  File Attributes  . . . . . . . . . . . . . . . . . . . . .  32  34
   5.1.  Mandatory Attributes . . . . . . . . . . . . . . . . . .  33  35
   5.2.  Recommended Attributes . . . . . . . . . . . . . . . . .  33  35
   5.3.  Named Attributes . . . . . . . . . . . . . . . . . . . .  33  35
   5.4.  Classification of Attributes . . . . . . . . . . . . . .  36
   5.5.  Mandatory Attributes - Definitions . . . . . . . . . . .  35
   5.5.  38
   5.6.  Recommended Attributes - Definitions . . . . . . . . . .  37
   5.6.  40
   5.7.  Time Access  . . . . . . . . . . . . . . . . . . . . . .  45
   5.8.  Interpreting owner and owner_group . . . . . . . . . . .  41
   5.7.  45
   5.9.  Character Case Attributes  . . . . . . . . . . . . . . .  43
   5.8.  47
   5.10.  Quota Attributes  . . . . . . . . . . . . . . . . . . . .  43
   5.9.  47
   5.11.  Access Control Lists  . . . . . . . . . . . . . . . . . .  44
   5.9.1.  48

Draft Specification      NFS version 4 Protocol              August 2002

   5.11.1.  ACE type  . . . . . . . . . . . . . . . . . . . . . .  49
   5.11.2.  ACE Access Mask .  45
   5.9.2. . . . . . . . . . . . . . . . . . .  50
   5.11.3.  ACE flag  . . . . . . . . . . . . . . . . . . . . . . .  45
   5.9.3.  52
   5.11.4.  ACE Access Mask who . . . . . . . . . . . . . . . . . . .  47
   5.9.4.  ACE who . . . .  53
   5.11.5.  Mode Attribute  . . . . . . . . . . . . . . . . . . .  48

Draft Specification      NFS version 4 Protocol                July 2002  54
   5.11.6.  Mode and ACL Attribute  . . . . . . . . . . . . . . .  55
   5.11.7.  mounted_on_fileid . . . . . . . . . . . . . . . . . .  55
   6.  File System  Filesystem Migration and Replication . . . . . . . . . .  49 .  57
   6.1.  Replication  . . . . . . . . . . . . . . . . . . . . . .  49  57
   6.2.  Migration  . . . . . . . . . . . . . . . . . . . . . . .  49  57
   6.3.  Interpretation of the fs_locations Attribute . . . . . .  50  58
   6.4.  Filehandle Recovery for Migration or Replication . . . .  51  59
   7.  NFS Server Name Space  . . . . . . . . . . . . . . . . . .  52  60
   7.1.  Server Exports . . . . . . . . . . . . . . . . . . . . .  52  60
   7.2.  Browsing Exports . . . . . . . . . . . . . . . . . . . .  52  60
   7.3.  Server Pseudo File System Filesystem . . . . . . . . . . . . . . .  52 .  60
   7.4.  Multiple Roots . . . . . . . . . . . . . . . . . . . . .  53  61
   7.5.  Filehandle Volatility  . . . . . . . . . . . . . . . . .  53  61
   7.6.  Exported Root  . . . . . . . . . . . . . . . . . . . . .  53  61
   7.7.  Mount Point Crossing . . . . . . . . . . . . . . . . . .  54  62
   7.8.  Security Policy and Name Space Presentation  . . . . . .  54  62
   8.  File Locking and Share Reservations  . . . . . . . . . . .  55  64
   8.1.  Locking  . . . . . . . . . . . . . . . . . . . . . . . .  55  64
   8.1.1.  Client ID  . . . . . . . . . . . . . . . . . . . . . .  55  64
   8.1.2.  Server Release of Clientid . . . . . . . . . . . . . .  57  67
   8.1.3.  nfs_lockowner  lock_owner and stateid Definition  . . . . . . . . .  58 .  68
   8.1.4.  Use of the stateid and Locking . . . . . . . . . . . . . . . . . .  59  69
   8.1.5.  Sequencing of Lock Requests  . . . . . . . . . . . . .  60  71
   8.1.6.  Recovery from Replayed Requests  . . . . . . . . . . .  61  72
   8.1.7.  Releasing nfs_lockowner lock_owner State . . . . . . . . . . . .  61 . .  72
   8.1.8.  Use of Open Confirmation . . . . . . . . . . . . . . .  73
   8.2.  Lock Ranges  . . . . . . . . . . . . . . . . . . . . . .  62  74
   8.3.  Upgrading and Downgrading Locks  . . . . . . . . . . . .  74
   8.4.  Blocking Locks . . . . . . . . . . . . . . . . . . . . .  62
   8.4.  75
   8.5.  Lease Renewal  . . . . . . . . . . . . . . . . . . . . .  63
   8.5.  75
   8.6.  Crash Recovery . . . . . . . . . . . . . . . . . . . . .  64
   8.5.1.  76
   8.6.1.  Client Failure and Recovery  . . . . . . . . . . . . .  64
   8.5.2.  76
   8.6.2.  Server Failure and Recovery  . . . . . . . . . . . . .  65
   8.5.3.  77
   8.6.3.  Network Partitions and Recovery  . . . . . . . . . . .  66
   8.6.  79
   8.7.  Recovery from a Lock Request Timeout or Abort  . . . . .  67
   8.7.  80
   8.8.  Server Revocation of Locks . . . . . . . . . . . . . . .  68
   8.8.  80
   8.9.  Share Reservations . . . . . . . . . . . . . . . . . . .  69
   8.9.  81
   8.10.  OPEN/CLOSE Operations . . . . . . . . . . . . . . . . .  69
   8.10.  82
   8.10.1.  Close and Retention of State Information  . . . . . .  83
   8.11.  Open Upgrade and Downgrade  . . . . . . . . . . . . . .  70
   8.11.  83
   8.12.  Short and Long Leases . . . . . . . . . . . . . . . . .  71
   8.12.  Clocks  84
   8.13.  Clocks, Propagation Delay, and Calculating Lease
          Expiration  . . . . . . . .  71
   8.13. . . . . . . . . . . . . . .  84
   8.14.  Migration, Replication and State  . . . . . . . . . . .  71
   8.13.1.  85
   8.14.1.  Migration and State . . . . . . . . . . . . . . . . .  72
   8.13.2.  85
   8.14.2.  Replication and State . . . . . . . . . . . . . . . .  72
   8.13.3.  86
   8.14.3.  Notification of Migrated Lease  . . . . . . . . . . .  73  86

Draft Specification      NFS version 4 Protocol              August 2002

   8.14.4.  Migration and the Lease_time Attribute  . . . . . . .  87
   9.  Client-Side Caching  . . . . . . . . . . . . . . . . . . .  74  88
   9.1.  Performance Challenges for Client-Side Caching . . . . .  74  88
   9.2.  Delegation and Callbacks . . . . . . . . . . . . . . . .  75  89
   9.2.1.  Delegation Recovery  . . . . . . . . . . . . . . . . .  76  90
   9.3.  Data Caching . . . . . . . . . . . . . . . . . . . . . .  78  92
   9.3.1.  Data Caching and OPENs . . . . . . . . . . . . . . . .  78  92
   9.3.2.  Data Caching and File Locking  . . . . . . . . . . . .  79  93
   9.3.3.  Data Caching and Mandatory File Locking  . . . . . . .  80  95
   9.3.4.  Data Caching and File Identity . . . . . . . . . . . .  81  95
   9.4.  Open Delegation  . . . . . . . . . . . . . . . . . . . .  82  96
   9.4.1.  Open Delegation and Data Caching . . . . . . . . . . .  84

Draft Specification      NFS version 4 Protocol                July 2002  99
   9.4.2.  Open Delegation and File Locks . . . . . . . . . . . .  85  100
   9.4.3.  Recall  Handling of Open Delegation CB_GETATTR . . . . . . . . . . . . . .  85 . .  100
   9.4.4.  Recall of Open Delegation Revocation  . . . . . . . . . . . . . .  102
   9.4.5.  Delegation Revocation  . .  87
   9.5. . . . . . . . . . . . . . .  104
   9.5.  Data Caching and Revocation  . . . . . . . . . . . . . .  87  104
   9.5.1.  Revocation Recovery for Write Open Delegation  . . . .  88  104
   9.6.  Attribute Caching  . . . . . . . . . . . . . . . . . . .  89  105
   9.7.  Name Caching . . . . . . . . . . . . . . . . . . . . . .  90  107
   9.8.  Directory Caching  . . . . . . . . . . . . . . . . . . .  91  108
   10.  Minor Versioning  . . . . . . . . . . . . . . . . . . . .  93  110
   11.  Internationalization  . . . . . . . . . . . . . . . . . .  96  113
   11.1.  Universal Versus Local Character Sets . . . . . . . . .  96  113
   11.2.  Overview of Universal Character Set Standards . . . . .  97  114
   11.3.  Difficulties with UCS-4, UCS-2, Unicode . . . . . . . .  98  115
   11.4.  UTF-8 and its solutions . . . . . . . . . . . . . . . .  98  115
   11.5.  Normalization . . . . . . . . . . . . . . . . . . . . .  99  116
   11.6.  UTF-8 Related Errors  . . . . . . . . . . . . . . . . .  116
   12.  Error Definitions . . . . . . . . . . . . . . . . . . . .  100  118
   13.  NFS Version version 4 Requests  . . . . . . . . . . . . . . . . .  105  124
   13.1.  Compound Procedure  . . . . . . . . . . . . . . . . . .  105  124
   13.2.  Evaluation of a Compound Request  . . . . . . . . . . .  106  125
   13.3.  Synchronous Modifying Operations  . . . . . . . . . . .  106  125
   13.4.  Operation Values  . . . . . . . . . . . . . . . . . . .  107  126
   14.  NFS Version version 4 Procedures  . . . . . . . . . . . . . . . .  108  127
   14.1.  Procedure 0: NULL - No Operation  . . . . . . . . . . .  108  127
   14.2.  Procedure 1: COMPOUND - Compound Operations . . . . . .  109  128
   14.2.1.  Operation 3: ACCESS - Check Access Rights . . . . . .  112  131
   14.2.2.  Operation 4: CLOSE - Close File . . . . . . . . . . .  115  134
   14.2.3.  Operation 5: COMMIT - Commit Cached Data  . . . . . .  117  136
   14.2.4.  Operation 6: CREATE - Create a Non-Regular File Object 120 139
   14.2.5.  Operation 7: DELEGPURGE - Purge Delegations Awaiting
            Recovery  . . . . . . . . . . . . . . . . . . . . . .  123  142
   14.2.6.  Operation 8: DELEGRETURN - Return Delegation  . . . .  124  143
   14.2.7.  Operation 9: GETATTR - Get Attributes . . . . . . . .  125  144
   14.2.8.  Operation 10: GETFH - Get Current Filehandle  . . . .  127  146
   14.2.9.  Operation 11: LINK - Create Link to a File  . . . . .  129  148
   14.2.10.  Operation 12: LOCK - Create Lock . . . . . . . . . .  131  150
   14.2.11.  Operation 13: LOCKT - Test For Lock  . . . . . . . .  134  154
   14.2.12.  Operation 14: LOCKU - Unlock File  . . . . . . . . .  136  156
   14.2.13.  Operation 15: LOOKUP - Lookup Filename . . . . . . .  138  158

Draft Specification      NFS version 4 Protocol              August 2002

   14.2.14.  Operation 16: LOOKUPP - Lookup Parent Directory  . .  141  161
   14.2.15.  Operation 17: NVERIFY - Verify Difference in
             Attributes . . . . . . . . . . . . . . . . . . . . .  143  162
   14.2.16.  Operation 18: OPEN - Open a Regular File . . . . . .  145  164
   14.2.17.  Operation 19: OPENATTR - Open Named Attribute
             Directory  . . . . . . . . . . . . . . . . . . . . .  154  174
   14.2.18.  Operation 20: OPEN_CONFIRM - Confirm Open  . . . . .  156  176
   14.2.19.  Operation 21: OPEN_DOWNGRADE - Reduce Open File Access159 Access179
   14.2.20.  Operation 22: PUTFH - Set Current Filehandle . . . .  161  181
   14.2.21.  Operation 23: PUTPUBFH - Set Public Filehandle . . .  162  182
   14.2.22.  Operation 24: PUTROOTFH - Set Root Filehandle  . . .  164  184
   14.2.23.  Operation 25: READ - Read from File  . . . . . . . .  165  185
   14.2.24.  Operation 26: READDIR - Read Directory . . . . . . .  168  188
   14.2.25.  Operation 27: READLINK - Read Symbolic Link  . . . .  172

Draft Specification      NFS version 4 Protocol                July 2002  192
   14.2.26.  Operation 28: REMOVE - Remove Filesystem Object  . .  174  194
   14.2.27.  Operation 29: RENAME - Rename Directory Entry  . . .  176  197
   14.2.28.  Operation 30: RENEW - Renew a Lease  . . . . . . . .  179  200
   14.2.29.  Operation 31: RESTOREFH - Restore Saved Filehandle .  180  201
   14.2.30.  Operation 32: SAVEFH - Save Current Filehandle . . .  182  203
   14.2.31.  Operation 33: SECINFO - Obtain Available Security  .  183  204
   14.2.32.  Operation 34: SETATTR - Set Attributes . . . . . . .  186  208
   14.2.33.  Operation 35: SETCLIENTID - Negotiate Clientid . . .  189  211
   14.2.34.  Operation 36: SETCLIENTID_CONFIRM - Confirm Clientid  191  215
   14.2.35.  Operation 37: VERIFY - Verify Same Attributes  . . .  192  219
   14.2.36.  Operation 38: WRITE - Write to File  . . . . . . . .  194  221
   14.2.37.  Operation 39: RELEASE_LOCKOWNER - Release Lockowner
             State  . . . . . . . . . . . . . . . . . . . . . . .  198  226
   14.2.38.  Operation 10044: ILLEGAL - Illegal operation . . . .  228
   15.  NFS Version version 4 Callback Procedures . . . . . . . . . . . .  199  229
   15.1.  Procedure 0: CB_NULL - No Operation . . . . . . . . . .  199  229
   15.2.  Procedure 1: CB_COMPOUND - Compound Operations  . . . .  200  230
   15.2.1.  Operation 3: CB_GETATTR - Get Attributes  . . . . . .  202  232
   15.2.2.  Operation 4: CB_RECALL - Recall an Open Delegation  .  203  234
   15.2.3.  Operation 10044: CB_ILLEGAL - Illegal Callback
            Operation . . . . . . . . . . . . . . . . . . . . . .  236
   16.  Security Considerations . . . . . . . . . . . . . . . . .  205  237
   17.  IANA Considerations . . . . . . . . . . . . . . . . . . .  206  238
   17.1.  Named Attribute Definition  . . . . . . . . . . . . . .  206  238
   17.2.  ONC RPC Network Identifiers (netids)  . . . . . . . . .  238
   18.  RPC definition file . . . . . . . . . . . . . . . . . . .  207  239
   19.  Bibliography  . . . . . . . . . . . . . . . . . . . . . .  238  271
   20.  Authors . . . . . . . . . . . . . . . . . . . . . . . . .  243  277
   20.1.  Editor's Address  . . . . . . . . . . . . . . . . . . .  243  277
   20.2.  Authors' Addresses  . . . . . . . . . . . . . . . . . .  243  277
   20.3.  Acknowledgements  . . . . . . . . . . . . . . . . . . .  244  278
   21.  Full Copyright Statement  . . . . . . . . . . . . . . . .  245  279

Draft Specification      NFS version 4 Protocol                July              August 2002

1.  Introduction

   The NFS version 4 protocol is a further revision of the NFS protocol
   defined already by versions 2 [RFC1094] and 3 [RFC1813].  It retains
   the essential characteristics of previous versions: design for easy
   recovery, independent of transport protocols, operating systems and
   filesystems, simplicity, and good performance.  The NFS version 4
   revision has the following goals:

   o    Improved access and good performance on the Internet.

        The protocol is designed to transit firewalls easily, perform
        well where latency is high and bandwidth is low, and scale to
        very large numbers of clients per server.

   o    Strong security with negotiation built into the protocol.

        The protocol builds on the work of the ONCRPC working group in
        supporting the RPCSEC_GSS protocol.  Additionally, the NFS
        version 4 protocol provides a mechanism to allow clients and
        servers the ability to negotiate security and require clients
        and servers to support a minimal set of security schemes.

   o    Good cross-platform interoperability.

        The protocol features a file system filesystem model that provides a useful,
        common set of features that does not unduly favor one
        file system filesystem
        or operating system over another.

   o    Designed for protocol extensions.

        The protocol is designed to accept standard extensions that do
        not compromise backward compatibility.

1.1.  Inconsistencies of this Document with Section 18

   Section 18, RPC Definition File, contains the definitions in XDR
   description language of the constructs used by the protocol.  Prior
   to Section 18, several of the constructs are reproduced for purposes
   of explanation.  The reader is warned of the possibility of errors in
   the reproduced constructs outside of Section 18.  For any part of the
   document that is inconsistent with Section 18, Section 18 is to be
   considered authoritative.

Draft Specification      NFS version 4 Protocol              August 2002

1.2.  Overview of NFS Version version 4 Features

   To provide a reasonable context for the reader, the major features of
   NFS version 4 protocol will be reviewed in brief.  This will be done
   to provide an appropriate context for both the reader who is familiar
   with the previous versions of the NFS protocol and the reader that is
   new to the NFS protocols.  For the reader new to the NFS protocols,
   there is still a fundamental knowledge that is expected.  The reader
   should be familiar with the XDR and RPC protocols as described in
   [RFC1831] and [RFC1832].  A basic knowledge of file systems filesystems and
   distributed file systems filesystems is expected as well.

Draft Specification      NFS version 4 Protocol                July 2002

1.1.1.

1.2.1.  RPC and Security

   As with previous versions of NFS, the External Data Representation
   (XDR) and Remote Procedure Call (RPC) mechanisms used for the NFS
   version 4 protocol are those defined in [RFC1831] and [RFC1832].  To
   meet end to end security requirements, the RPCSEC_GSS framework
   [RFC2203] will be used to extend the basic RPC security.  With the
   use of RPCSEC_GSS, various mechanisms can be provided to offer
   authentication, integrity, and privacy to the NFS version 4 protocol.
   Kerberos V5 will be used as described in [RFC1964] to provide one
   security framework.  The LIPKEY GSS-API mechanism described in
   [RFC2847] will be used to provide for the use of user password and
   server public key by the NFS version 4 protocol.  With the use of
   RPCSEC_GSS, other mechanisms may also be specified and used for NFS
   version 4 security.

   To enable in-band security negotiation, the NFS version 4 protocol
   has added a new operation which provides the client a method of
   querying the server about its policies regarding which security
   mechanisms must be used for access to the server's file system filesystem
   resources.  With this, the client can securely match the security
   mechanism that meets the policies specified at both the client and
   server.

1.1.2.

1.2.2.  Procedure and Operation Structure

   A significant departure from the previous versions of the NFS
   protocol is the introduction of the COMPOUND procedure.  For the NFS
   version 4 protocol, there are two RPC procedures, NULL and COMPOUND.
   The COMPOUND procedure is defined in terms of operations and these
   operations correspond more closely to the traditional NFS procedures.
   With the use of the COMPOUND procedure, the client is able to build
   simple or complex requests.  These COMPOUND requests allow for a
   reduction in the number of RPCs needed for logical file system filesystem
   operations.  For example, without previous contact with a server a
   client will be able to read data from a file in one request by
   combining LOOKUP, OPEN, and READ operations in a single COMPOUND RPC.
   With previous versions of the NFS protocol, this type of single

Draft Specification      NFS version 4 Protocol              August 2002

   request was not possible.

   The model used for COMPOUND is very simple.  There is no logical OR
   or ANDing of operations.  The operations combined within a COMPOUND
   request are evaluated in order by the server.  Once an operation
   returns a failing result, the evaluation ends and the results of all
   evaluated operations are returned to the client.

   The NFS version 4 protocol continues to have the client refer to a
   file or directory at the server by a "filehandle".  The COMPOUND
   procedure has a method of passing a filehandle from one operation to
   another within the sequence of operations.  There is a concept of a
   "current filehandle" and "saved filehandle".  Most operations use the

Draft Specification      NFS version 4 Protocol                July 2002
   "current filehandle" as the file system filesystem object to operate upon.  The
   "saved filehandle" is used as temporary filehandle storage within a
   COMPOUND procedure as well as an additional operand for certain
   operations.

1.1.3.  File System

1.2.3.  Filesystem Model

   The general file system filesystem model used for the NFS version 4 protocol is
   the same as previous versions.  The server file system filesystem is hierarchical
   with the regular files contained within being treated as opaque byte
   streams.  In a slight departure, file and directory names are encoded
   with UTF-8 to deal with the basics of internationalization.

   The NFS version 4 protocol does not require a separate protocol to
   provide for the initial mapping between path name and filehandle.
   Instead of using the older MOUNT protocol for this mapping, the
   server provides a ROOT filehandle that represents the logical root or
   top of the file system filesystem tree provided by the server.  The server
   provides multiple file systems filesystems by glueing them together with pseudo
   file systems.
   filesystems.  These pseudo file systems filesystems provide for potential gaps in
   the path names between real file systems.

1.1.3.1. filesystems.

1.2.3.1.  Filehandle Types

   In previous versions of the NFS protocol, the filehandle provided by
   the server was guaranteed to be valid or persistent for the lifetime
   of the file system filesystem object to which it referred.  For some server
   implementations, this persistence requirement has been difficult to
   meet.  For the NFS version 4 protocol, this requirement has been
   relaxed by introducing another type of filehandle, volatile.  With
   persistent and volatile filehandle types, the server implementation
   can match the abilities of the file system filesystem at the server along with
   the operating environment.  The client will have knowledge of the
   type of filehandle being provided by the server and can be prepared
   to deal with the semantics of each.

1.1.3.2.

Draft Specification      NFS version 4 Protocol              August 2002

1.2.3.2.  Attribute Types

   The NFS version 4 protocol introduces three classes of file system filesystem or
   file attributes.  Like the additional filehandle type, the
   classification of file attributes has been done to ease server
   implementations along with extending the overall functionality of the
   NFS protocol.  This attribute model is structured to be extensible
   such that new attributes can be introduced in minor revisions of the
   protocol without requiring significant rework.

   The three classifications are: mandatory, recommended and named
   attributes.  This is a significant departure from the previous

Draft Specification      NFS version 4 Protocol                July 2002
   attribute model used in the NFS protocol.  Previously, the attributes
   for the file system filesystem and file objects were a fixed set of mainly Unix UNIX
   attributes.  If the server or client did not support a particular
   attribute, it would have to simulate the attribute the best it could.

   Mandatory attributes are the minimal set of file or file system filesystem
   attributes that must be provided by the server and must be properly
   represented by the server.  Recommended attributes represent
   different file system filesystem types and operating environments.  The
   recommended attributes will allow for better interoperability and the
   inclusion of more operating environments.  The mandatory and
   recommended attribute sets are traditional file or file system filesystem
   attributes.  The third type of attribute is the named attribute.  A
   named attribute is an opaque byte stream that is associated with a
   directory or file and referred to by a string name.  Named attributes
   are meant to be used by client applications as a method to associate
   application specific data with a regular file or directory.

   One significant addition to the recommended set of file attributes is
   the Access Control List (ACL) attribute.  This attribute provides for
   directory and file access control beyond the model used in previous
   versions of the NFS protocol.  The ACL definition allows for
   specification of user and group level access control.

1.1.3.3.  File System

1.2.3.3.  Filesystem Replication and Migration

   With the use of a special file attribute, the ability to migrate or
   replicate server file systems filesystems is enabled within the protocol.  The
   file system
   filesystem locations attribute provides a method for the client to
   probe the server about the location of a file system. filesystem.  In the event of
   a migration of a file system, filesystem, the client will receive an error when
   operating on the file system filesystem and it can then query as to the new file
   system location.  Similar steps are used for replication, the client
   is able to query the server for the multiple available locations of a
   particular file system. filesystem.  From this information, the client can use its
   own policies to access the appropriate file system filesystem location.

1.1.4.

Draft Specification      NFS version 4 Protocol              August 2002

1.2.4.  OPEN and CLOSE

   The NFS version 4 protocol introduces OPEN and CLOSE operations.  The
   OPEN operation provides a single point where file lookup, creation,
   and share semantics can be combined.  The CLOSE operation also
   provides for the release of state accumulated by OPEN.

1.1.5.

1.2.5.  File locking

   With the NFS version 4 protocol, the support for byte range file
   locking is part of the NFS protocol.  The file locking support is

Draft Specification      NFS version 4 Protocol                July 2002
   structured so that an RPC callback mechanism is not required.  This
   is a departure from the previous versions of the NFS file locking
   protocol, Network Lock Manager (NLM).  The state associated with file
   locks is maintained at the server under a lease-based model.  The
   server defines a single lease period for all state held by a NFS
   client.  If the client does not renew its lease within the defined
   period, all state associated with the client's lease may be released
   by the server.  The client may renew its lease with use of the RENEW
   operation or implicitly by use of other operations (primarily READ).

1.1.6.

1.2.6.  Client Caching and Delegation

   The file, attribute, and directory caching for the NFS version 4
   protocol is similar to previous versions.  Attributes and directory
   information are cached for a duration determined by the client.  At
   the end of a predefined timeout, the client will query the server to
   see if the related file system filesystem object has been updated.

   For file data, the client checks its cache validity when the file is
   opened.  A query is sent to the server to determine if the file has
   been changed.  Based on this information, the client determines if
   the data cache for the file should kept or released.  Also, when the
   file is closed, any modified data is written to the server.

   If an application wants to serialize access to file data, file
   locking of the file data ranges in question should be used.

   The major addition to NFS version 4 in the area of caching is the
   ability of the server to delegate certain responsibilities to the
   client.  When the server grants a delegation for a file to a client,
   the client is guaranteed certain semantics with respect to the
   sharing of that file with other clients.  At OPEN, the server may
   provide the client either a read or write delegation for the file.
   If the client is granted a read delegation, it is assured that no
   other client has the ability to write to the file for the duration of
   the delegation.  If the client is granted a write delegation, the
   client is assured that no other client has read or write access to
   the file.

Draft Specification      NFS version 4 Protocol              August 2002

   Delegations can be recalled by the server.  If another client
   requests access to the file in such a way that the access conflicts
   with the granted delegation, the server is able to notify the initial
   client and recall the delegation.  This requires that a callback path
   exist between the server and client.  If this callback path does not
   exist, then delegations can not be granted.  The essence of a
   delegation is that it allows the client to locally service operations
   such as OPEN, CLOSE, LOCK, LOCKU, READ, WRITE without immediate
   interaction with the server.

Draft Specification      NFS version 4 Protocol                July 2002

1.2.

1.3.  General Definitions

   The following definitions are provided for the purpose of providing
   an appropriate context for the reader.

   Client    The "client" is the entity that accesses the NFS server's
             resources.  The client may be an application which contains
             the logic to access the NFS server directly.  The client
             may also be the traditional operating system client remote
             file system
             filesystem services for a set of applications.

             In the case of file locking the client is the entity that
             maintains a set of locks on behalf of one or more
             applications.  This client is responsible for crash or
             failure recovery for those locks it manages.

             Note that multiple clients may share the same transport and
             multiple clients may exist on the same network node.

   Clientid  A 64-bit quantity used as a unique, short-hand reference to
             a client supplied Verifier and ID.  The server is
             responsible for supplying the Clientid.

   Lease     An interval of time defined by the server for which the
             client is irrevocably granted a lock.  At the end of a
             lease period the lock may be revoked if the lease has not
             been extended.  The lock must be revoked if a conflicting
             lock has been granted after the lease interval.

             All leases granted by a server have the same fixed
             interval.  Note that the fixed interval was chosen to
             alleviate the expense a server would have in maintaining
             state about variable length leases across server failures.

   Lock      The term "lock" is used to refer to both record (byte-
             range) locks as well as file (share) locks share reservations unless
             specifically stated otherwise.

   Server    The "Server" is the entity responsible for coordinating
             client access to a set of file systems. filesystems.

Draft Specification      NFS version 4 Protocol              August 2002

   Stable Storage
             NFS version 4 servers must be able to recover without data
             loss from multiple power failures (including cascading
             power failures, that is, several power failures in quick
             succession), operating system failures, and hardware
             failure of components other than the storage medium itself
             (for example, disk, nonvolatile RAM).

             Some examples of stable storage that are allowable for an
             NFS server include:

Draft Specification      NFS version 4 Protocol                July 2002

             1. Media commit of data, that is, the modified data has
                been successfully written to the disk media,
                for example, the disk platter.

             2. An immediate reply disk drive with battery-backed
                on-drive intermediate storage or uninterruptible power
                system (UPS).

             3. Server commit of data with battery-backed intermediate
                storage and recovery software.

             4. Cache commit with uninterruptible power system (UPS)
                and recovery software.

   Stateid   A 128-bit quantity returned by a server that uniquely
             defines the open and locking state provided by the server
             for a specific open or lock owner for a specific file.

             Stateids composed of all bits 0 or all bits 1 have special
             meaning and are reserved values.

   Verifier  A 64-bit quantity generated by the client that the server
             can use to determine if the client has restarted and lost
             all previous lock state.

Draft Specification      NFS version 4 Protocol                July              August 2002

2.  Protocol Data Types

   The syntax and semantics to describe the data types of the NFS
   version 4 protocol are defined in the XDR [RFC1832] and RPC [RFC1831]
   documents.  The next sections build upon the XDR data types to define
   types and structures specific to this protocol.

2.1.  Basic Data Types

   Data Type     Definition
   _____________________________________________________________________
   int32_t       typedef int             int32_t;

   uint32_t      typedef unsigned int    uint32_t;

   int64_t       typedef hyper           int64_t;

   uint64_t      typedef unsigned hyper  uint64_t;

   attrlist4     typedef opaque        attrlist4<>;
                 Used for file/directory attributes

   bitmap4       typedef uint32_t        bitmap4<>;
                 Used in attribute array encoding.

   changeid4     typedef       uint64_t        changeid4;
                 Used in definition of change_info

   clientid4     typedef uint64_t        clientid4;
                 Shorthand reference to client identification

   component4    typedef utf8string      component4;
                 Represents path name components

   count4        typedef uint32_t        count4;
                 Various count parameters (READ, WRITE, COMMIT)

   length4       typedef uint64_t        length4;
                 Describes LOCK lengths

   linktext4     typedef utf8string      linktext4;
                 Symbolic link contents

   mode4         typedef uint32_t        mode4;
                 Mode attribute data type

   nfs_cookie4   typedef uint64_t        nfs_cookie4;
                 Opaque cookie value for READDIR

   nfs_fh4       typedef opaque          nfs_fh4<NFS4_FHSIZE>;
                 Filehandle definition; NFS4_FHSIZE is defined as 128

Draft Specification      NFS version 4 Protocol                July              August 2002

   nfs_ftype4    enum nfs_ftype4;
                 Various defined file types

   nfsstat4      enum nfsstat4;
                 Return value for operations

   offset4       typedef uint64_t        offset4;
                 Various offset designations (READ, WRITE, LOCK, COMMIT)

   pathname4     typedef component4      pathname4<>;
                 Represents path name for LOOKUP, OPEN and others

   qop4          typedef uint32_t        qop4;
                 Quality of protection designation in SECINFO

   sec_oid4      typedef opaque          sec_oid4<>;
                 Security Object Identifier
                 The sec_oid4 data type is not really opaque.
                 Instead contains an ASN.1 OBJECT IDENTIFIER as used
                 by GSS-API in the mech_type argument to
                 GSS_Init_sec_context.  See [RFC2078] [RFC2743] for details.

   seqid4        typedef uint32_t        seqid4;
                 Sequence identifier used for file locking

   utf8string    typedef opaque          utf8string<>;
                 UTF-8 encoding for strings

   verifier4     typedef opaque        verifier4[NFS4_VERIFIER_SIZE];
                 Verifier used for various operations (COMMIT, CREATE,
                 OPEN, READDIR, SETCLIENTID, SETCLIENTID_CONFIRM, WRITE)
                 NFS4_VERIFIER_SIZE is defined as 8

2.2.  Structured Data Types

   nfstime4
                  struct nfstime4 {
                          int64_t seconds;
                          uint32_t nseconds;
                  }

        The nfstime4 structure gives the number of seconds and
        nanoseconds since midnight or 0 hour January 1, 1970 Coordinated
        Universal Time (UTC).  Values greater than zero for the seconds
        field denote dates after the 0 hour January 1, 1970.  Values
        less than zero for the seconds field denote dates before the 0
        hour January 1, 1970.  In both cases, the nseconds field is to
        be added to the seconds field for the final time representation.
        For example, if the time to be represented is one-half second

Draft Specification      NFS version 4 Protocol              August 2002

        before 0 hour January 1, 1970, the seconds field would have a

Draft Specification      NFS version 4 Protocol                July 2002
        value of negative one (-1) and the nseconds fields would have a
        value of one-half second (500000000).  Values greater than
        999,999,999 for nseconds are considered invalid.

        This data type is used to pass time and date information.  A
        server converts to and from its local representation of time
        when processing time values, preserving as much accuracy as
        possible. If the precision of timestamps stored for a file
        system filesystem
        object is less than defined, loss of precision can occur.  An
        adjunct time maintenance protocol is recommended to reduce
        client and server time skew.

   time_how4

                  enum time_how4 {
                          SET_TO_SERVER_TIME4 = 0,
                          SET_TO_CLIENT_TIME4 = 1
                  };

   settime4

                  union settime4 switch (time_how4 set_it) {
                   case SET_TO_CLIENT_TIME4:
                           nfstime4       time;
                   default:
                           void;
                  };

        The above definitions are used as the attribute definitions to
        set time values.  If set_it is SET_TO_SERVER_TIME4, then the
        server uses its local representation of time for the time value.

   specdata4

                  struct specdata4 {
                          uint32_t specdata1; /* major device number */
                          uint32_t specdata2; /* minor device number */
                  };

        This data type represents additional information for the device
        file types NF4CHR and NF4BLK.

   fsid4

                  struct fsid4 {
                    uint64_t        major;
                    uint64_t        minor;
                  };

Draft Specification      NFS version 4 Protocol                July              August 2002

                  };

        This type is the file system filesystem identifier that is used as a
        mandatory attribute.

   fs_location4

                  struct fs_location4 {
                          utf8string    server<>;
                          pathname4     rootpath;
                  };

   fs_locations4

                  struct fs_locations4 {
                          pathname4     fs_root;
                          fs_location4  locations<>;
                  };

        The fs_location4 and fs_locations4 data types are used for the
        fs_locations recommended attribute which is used for migration
        and replication support.

   fattr4

                  struct fattr4 {
                          bitmap4       attrmask;
                          attrlist4     attr_vals;
                  };

        The fattr4 structure is used to represent file and directory
        attributes.

        The bitmap is a counted array of 32 bit integers used to contain
        bit values.  The position of the integer in the array that
        contains bit n can be computed from the expression (n / 32) and
        its bit within that integer is (n mod 32).

                                      0            1
                    +-----------+-----------+-----------+--
                    |  count    | 31  ..  0 | 63  .. 32 |
                    +-----------+-----------+-----------+--

   change_info4

                  struct change_info4 {
                          bool          atomic;
                          changeid4     before;
                          changeid4     after;
                  };

Draft Specification      NFS version 4 Protocol                July              August 2002

                          changeid4     after;
                  };

        This structure is used with the CREATE, LINK, REMOVE, RENAME
        operations to let the client know the value of the change
        attribute for the directory in which the target file system filesystem
        object resides.

   clientaddr4

                  struct clientaddr4 {
                          /* see struct rpcb in RFC 1833 RFC1833 */
                          string r_netid<>;    /* network id */
                          string r_addr<>;     /* universal address */
                  };

        The clientaddr4 structure is used as part of the SETCLIENT SETCLIENTID
        operation to either specify the address of the client that is
        using a clientid or as part of the call back callback registration.

   cb_client4

                  struct cb_client4 {
                          unsigned int  cb_program;
                          clientaddr4   cb_location;
                  };

        This structure is used by the client to inform the server of its
        call back address; includes the program  The
        r_netid and r_addr fields are specified in [RFC1833], but they
        are underspecified in [RFC1833] as far as what they should look
        like for specific protocols.

        For TCP over IPv4 and for UDP over IPv4, the format of r_addr is
        the US-ASCII string:

             h1.h2.h3.h4.p1.p2

        The prefix, "h1.h2.h3.h4", is the standard textual form for
        representing an IPv4 address, which is always four octets long.
        Assuming big-endian ordering, h1, h2, h3, and h4, are
        respectively, the first through fourth octets each converted to
        ASCII-decimal.  Assuming big-endian ordering, p1 and p2 are,
        respectively, the first and second octets each converted to
        ASCII-decimal. For example, if a host, in big-endian order, has
        an address of 0x0A010307 and there is a service listening on, in
        big endian order, port 0x020F (decimal 527), then complete
        universal address is "10.1.3.7.2.15".

        For TCP over IPv4 the value of r_netid is the string "tcp".  For
        UDP over IPv4 the value of r_netid is the string "udp".

        For TCP over IPv4 and for UDP over IPv6, the format of r_addr is
        the US-ASCII string:

             x1:x2:x3:x4:x5:x6:x7:x8.p1.p2

        The suffix "p1.p2" is the service port, and is computed the same
        way as with univeral addresses for TCP and UDP over IPv4. The
        prefix, "x1:x2:x3:x4:x5:x6:x7:x8", is the standard textual form
        for representing an IPv6 address as defined in Section 2.2 of

Draft Specification      NFS version 4 Protocol              August 2002

        [RFC1884].  Additionally, the two alternative forms specified in
        Section 2.2 of [RFC1884] are also acceptable.

        For TCP over IPv6 the value of r_netid is the string "tcp6".
        For UDP over IPv6 the value of r_netid is the string "udp6".

   cb_client4

                  struct cb_client4 {
                          unsigned int  cb_program;
                          clientaddr4   cb_location;
                  };

        This structure is used by the client to inform the server of its
        call back address; includes the program number and client
        address.

   nfs_client_id4

                  struct nfs_client_id4 {
                          verifier4     verifier;
                          opaque        id<NFS4_OPAQUE_LIMIT>;
                  };

        This structure is part of the arguments to the SETCLIENTID
        operation.  NFS4_OPAQUE_LIMIT is defined as 1024.

   open_owner4

                  struct open_owner4 {
                          clientid4     clientid;
                          opaque        owner<NFS4_OPAQUE_LIMIT>;
                  };

        This structure is used to identify the owner of open state.
        NFS4_OPAQUE_LIMIT is defined as 1024.

Draft Specification      NFS version 4 Protocol                July 2002

   lock_owner4

                  struct nfs_lockowner4 lock_owner4 {
                          clientid4     clientid;
                          opaque        owner<NFS4_OPAQUE_LIMIT>;
                  };

        This structure is used to identify the owner of file locking
        state.  NFS4_OPAQUE_LIMIT is defined as 1024.

Draft Specification      NFS version 4 Protocol              August 2002

   open_to_lock_owner4

               struct open_to_lock_owner4 {
               seqid4          open_seqid;
               stateid4        open_stateid;
               seqid4          lock_seqid;
               lock_owner4     lock_owner;
               };

        This structure is used for the first LOCK operation done for an
        open_owner4.  It provides both the open_stateid and lock_owner
        such that the transition is made from a valid open_stateid
        sequence to that of the new lock_stateid sequence.  Using this
        mechanism avoids the confirmation of the lock_owner/lock_seqid
        pair since it is tied to established state in the form of the
        open_stateid/open_seqid.

   stateid4

                  struct stateid4 {
                    uint32_t        seqid;
                    opaque          other[12];
                  };

        This strucutre structure is used for the various state sharing mechanisms
        between the client and server.  For the client, this data
        structure is read-only.  The seqid starting value of the seqid field
        is undefined. The server is required to increment the only seqid
        field that monotonically at each transition of the client should interpret.  See stateid.  This is
        important since the section for client will inspect the seqid in OPEN
        operation for further description
        stateids to determine the order of how OPEN processing done by the seqid field is to
        be interpreted.
        server.

Draft Specification      NFS version 4 Protocol                July              August 2002

3.  RPC and Security Flavor

   The NFS version 4 protocol is a Remote Procedure Call (RPC)
   application that uses RPC version 2 and the corresponding eXternal
   Data Representation (XDR) as defined in [RFC1831] and [RFC1832].  The
   RPCSEC_GSS security flavor as defined in [RFC2203] MUST be used as
   the mechanism to deliver stronger security for the NFS version 4
   protocol.

3.1.  Ports and Transports

   Historically, NFS version 2 and version 3 servers have resided on
   port 2049.  The registered port 2049 [RFC1700] for the NFS protocol
   should be the default configuration.  Using the registered port for
   NFS services means the NFS client will not need to use the RPC
   binding protocols as described in [RFC1833]; this will allow NFS to
   transit firewalls.

   The transport used by the RPC service for the NFS version 4 protocol
   MUST provide congestion control comparable to that defined for TCP in
   [RFC2581].  If the operating environment implements TCP, the NFS
   version 4 protocol SHOULD be supported over TCP.  The NFS client and
   server may MAY use other transports if they support congestion control as
   defined above and in those cases a mechanism may be provided to
   override TCP usage in favor of another transport.

   If TCP is used as the transport, the client and server SHOULD use
   persistent connections.  This will prevent the weakening of TCP's
   congestion control via short lived connections and will improve
   performance for the WAN environment by eliminating the need for SYN
   handshakes.

   Note that for various timers, the client and server should avoid
   inadvertent synchronization of those timers.  For further discussion
   of the general issue refer to [Floyd].

3.2.  Security Flavors

   Traditional RPC implementations have included AUTH_NONE, AUTH_SYS,
   AUTH_DH, and AUTH_KRB4

3.1.1.  Client Retransmission Behavior

   When processing a request received over a reliable transport such as security flavors.  With [RFC2203] an
   additional security flavor of RPCSEC_GSS has been introduced which
   uses the functionality of GSS-API [RFC2078].  This allows for the use
   of varying security mechanisms by the RPC layer without
   TCP, the
   additional implementation overhead of adding RPC security flavors.
   For NFS version 4, the RPCSEC_GSS security flavor 4 server MUST be used to
   enable NOT silently drop the mandatory security mechanism.  Other flavors, request,
   except if the transport connection has been broken. Given such as,
   AUTH_NONE, AUTH_SYS, and AUTH_DH MAY be implemented as well.

3.2.1.  Security mechanisms for NFS version 4

   The use of RPCSEC_GSS requires selection of: mechanism, quality of

Draft Specification a
   contract between NFS version 4 Protocol                July 2002

   protection, clients and service (authentication, integrity, privacy).  The
   remainder servers, clients MUST NOT
   retry a request unless one or both of this the following are true:

   o    The transport connection has been broken

   o    The procedure being retried is the NULL procedure

   Since transports, including TCP, do not always synchronously inform a
   peer when the other peer has broken the connection (for example, when

Draft Specification      NFS version 4 Protocol              August 2002

   an NFS server reboots), so the NFS version 4 client may want to
   actively "probe" the connection to see if has been broken.  Use of
   the NULL procedure is one recommended way to do so.  So, when a
   client experiences a remote procedure call timeout (of some arbitrary
   implementation specific amount), rather than retrying the remote
   procedure call, it could instead issue a NULL procedure call to the
   server. If the server has died, the transport connection break will
   eventually be indicated to the NFS version 4 client. The client can
   then reconnect, and then retry the original request. If the NULL
   procedure call gets a response, the connection has not broken.  The
   client can decide to wait longer for the original request's response,
   or it can break the transport connection and reconnect before re-
   sending the original request.

   For callbacks from the server to the client, the same rules apply,
   but the server doing the callback becomes the client, and the client
   receiving the callback becomes the server.

3.2.  Security Flavors

   Traditional RPC implementations have included AUTH_NONE, AUTH_SYS,
   AUTH_DH, and AUTH_KRB4 as security flavors.  With [RFC2203] an
   additional security flavor of RPCSEC_GSS has been introduced which
   uses the functionality of GSS-API [RFC2743].  This allows for the use
   of various security mechanisms by the RPC layer without the
   additional implementation overhead of adding RPC security flavors.
   For NFS version 4, the RPCSEC_GSS security flavor MUST be used to
   enable the mandatory security mechanism.  Other flavors, such as,
   AUTH_NONE, AUTH_SYS, and AUTH_DH MAY be implemented as well.

3.2.1.  Security mechanisms for NFS version 4

   The use of RPCSEC_GSS requires selection of: mechanism, quality of
   protection, and service (authentication, integrity, privacy).  The
   remainder of this document will refer to these three parameters of
   the RPCSEC_GSS security as the security triple.

3.2.1.1.  Kerberos V5 as a security triple

   The Kerberos V5 GSS-API mechanism as described in [RFC1964] MUST be
   implemented and provide the following security triples.

 column descriptions:

 1 == number of pseudo flavor
 2 == name of pseudo flavor
 3 == mechanism's OID
 4 == mechanism's algorithm(s)
 5 == RPCSEC_GSS service

 1      2     3                    4              5

Draft Specification      NFS version 4 Protocol              August 2002

 -----------------------------------------------------------------------
 390003 krb5  1.2.840.113554.1.2.2 DES MAC MD5    rpc_gss_svc_none
 390004 krb5i 1.2.840.113554.1.2.2 DES MAC MD5    rpc_gss_svc_integrity
 390005 krb5p 1.2.840.113554.1.2.2 DES MAC MD5    rpc_gss_svc_privacy
                                   for integrity,
                                   and 56 bit DES
                                   for privacy.

   Note that the pseudo flavor is presented here as a mapping aid to the
   implementor.  Because this NFS protocol includes a method to
   negotiate security and it understands the GSS-API mechanism, the
   pseudo flavor is not needed.  The pseudo flavor is needed for NFS
   version 3 since the security negotiation is done via the MOUNT
   protocol.

   For a discussion of NFS' use of RPCSEC_GSS and Kerberos V5, please
   see [RFC2623].

3.2.1.2.  LIPKEY as a security triple

   The LIPKEY GSS-API mechanism as described in [RFC2847] MUST be
   implemented and provide the following security triples. The
   definition of the columns matches the previous subsection "Kerberos
   V5 as security triple"

 1      2        3                    4              5
 -----------------------------------------------------------------------
 390006 lipkey   1.3.6.1.5.5.9        negotiated  rpc_gss_svc_none
 390007 lipkey-i 1.3.6.1.5.5.9        negotiated  rpc_gss_svc_integrity
 390008 lipkey-p 1.3.6.1.5.5.9        negotiated  rpc_gss_svc_privacy

   The mechanism algorithm is listed as "negotiated".  This is because
   LIPKEY is layered on SPKM-3 and in SPKM-3 [RFC2847] the

Draft Specification      NFS version 4 Protocol                July 2002
   confidentiality and integrity algorithms are negotiated.  Since
   SPKM-3 specifies HMAC-MD5 for integrity as MANDATORY, 128 bit
   cast5CBC for confidentiality for privacy as MANDATORY, and further
   specifies that HMAC-MD5 and cast5CBC MUST be listed first before
   weaker algorithms, specifying "negotiated" in column 4 does not
   impair interoperability.  In the event an SPKM-3 peer does not
   support the mandatory algorithms, the other peer is free to accept or
   reject the GSS-API context creation.

   Because SPKM-3 negotiates the algorithms, subsequent calls to
   LIPKEY's GSS_Wrap() and GSS_GetMIC() by RPCSEC_GSS will use a quality
   of protection value of 0 (zero).  See section 5.2 of [RFC2025] for an
   explanation.

   LIPKEY uses SPKM-3 to create a secure channel in which to pass a user
   name and password from the client to the server.  Once the user name
   and password have been accepted by the server, calls to the LIPKEY
   context are redirected to the SPKM-3 context. See [RFC2847] for more

Draft Specification      NFS version 4 Protocol              August 2002

   details.

3.2.1.3.  SPKM-3 as a security triple

   The SPKM-3 GSS-API mechanism as described in [RFC2847] MUST be
   implemented and provide the following security triples. The
   definition of the columns matches the previous subsection "Kerberos
   V5 as security triple".

 1      2        3                    4              5
 -----------------------------------------------------------------------
 390009 spkm3    1.3.6.1.5.5.1.3      negotiated  rpc_gss_svc_none
 390010 spkm3i   1.3.6.1.5.5.1.3      negotiated  rpc_gss_svc_integrity
 390011 spkm3p   1.3.6.1.5.5.1.3      negotiated  rpc_gss_svc_privacy

   For a discussion as to why the mechanism algorithm is listed as
   "negotiated", see the previous section "LIPKEY as a security triple."

   Because SPKM-3 negotiates the algorithms, subsequent calls to SPKM-
   3's GSS_Wrap() and GSS_GetMIC() by RPCSEC_GSS will use a quality of
   protection value of 0 (zero). See section 5.2 of [RFC2025] for an
   explanation.

   Even though LIPKEY is layered over SPKM-3, SPKM-3 is specified as a
   mandatory set of triples to handle the situations where the initiator
   (the client) is anonymous or where the initiator has its own
   certificate.  If the initiator is anonymous, there will not be a user
   name and password to send to the target (the server).  If the
   initiator has its own certificate, then using passwords is
   superfluous.

Draft Specification      NFS version 4 Protocol                July 2002

3.3.  Security Negotiation

   With the NFS version 4 server potentially offering multiple security
   mechanisms, the client needs a method to determine or negotiate which
   mechanism is to be used for its communication with the server.  The
   NFS server may have multiple points within its file system filesystem name space
   that are available for use by NFS clients.  In turn the NFS server
   may be configured such that each of these entry points may have
   different or multiple security mechanisms in use.

   The security negotiation between client and server must be done with
   a secure channel to eliminate the possibility of a third party
   intercepting the negotiation sequence and forcing the client and
   server to choose a lower level of security than required or desired.
   See the section "Security Considerations" for further discussion.

Draft Specification      NFS version 4 Protocol              August 2002

3.3.1.  SECINFO

   The new SECINFO operation will allow the client to determine, on a
   per filehandle basis, what security triple is to be used for server
   access.  In general, the client will not have to use the SECINFO
   operation except during initial communication with the server or when
   the client crosses policy boundaries at the server.  It is possible
   that the server's policies change during the client's interaction
   therefore forcing the client to negotiate a new security triple.

3.3.2.  Security Error

   Based on the assumption that each NFS version 4 client and server
   must support a minimum set of security (i.e. LIPKEY, SPKM-3, and
   Kerberos-V5 all under RPCSEC_GSS), the NFS client will start its
   communication with the server with one of the minimal security
   triples.  During communication with the server, the client may
   receive an NFS error of NFS4ERR_WRONGSEC.  This error allows the
   server to notify the client that the security triple currently being
   used is not appropriate for access to the server's file system filesystem
   resources.  The client is then responsible for determining what
   security triples are available at the server and choose one which is
   appropriate for the client.

3.3.2.  SECINFO

   The new SECINFO operation will allow  See the client to determine, on a
   per filehandle basis, what security triple is to be used section for server
   access.  In general, the "SECINFO"
   operation for further discussion of how the client will not have respond to
   the NFS4ERR_WRONGSEC error and use SECINFO.

3.4.  Callback RPC Authentication

   Except as noted elsewhere in this section, the SECINFO
   procedure except during initial communication with callback RPC
   (described later) MUST mutually authenticate the NFS server or when
   the client crosses policy boundaries at the server.  It is possible
   that the server's policies change during the client's interaction
   therefore forcing the client to negotiate a new security triple.

3.4.  Callback RPC Authentication

   The callback RPC (described later) must mutually authenticate the NFS
   server to to the
   principal that acquired the clientid (also described later), using
   the same security flavor the original SETCLIENTID operation used. Because LIPKEY is layered over SPKM-3, it is
   permissible for the server to use SPKM-3 and not LIPKEY for the
   callback even if the client used LIPKEY for SETCLIENTID.

   For AUTH_NONE, there are no principals, so this is a non-issue.

Draft Specification      NFS version 4 Protocol                July 2002

   For AUTH_SYS,

   AUTH_SYS has no notions of mutual authentation or a server principal,
   so the callback from the server simply uses the AUTH_SYS credential
   that the user used when it he set up the delegation.

   For AUTH_DH, one commonly used convention is that the server uses the
   credential corresponding to this AUTH_DH principal:

           unix.host@domain

   where host and domain are variables corresponding to the name of
   server host and directory services domain in which it lives such as a
   Network Information System domain or a DNS domain.

   Because LIPKEY is layered over SPKM-3, it is permissible for the
   server to use SPKM-3 and not LIPKEY for the callback even if the

Draft Specification      NFS version 4 Protocol              August 2002

   client used LIPKEY for SETCLIENTID.

   Regardless of what security mechanism under RPCSEC_GSS is being used,
   the NFS server, MUST identify itself in GSS-API via a
   GSS_C_NT_HOSTBASED_SERVICE name type.  GSS_C_NT_HOSTBASED_SERVICE
   names are of the form:

           service@hostname

   For NFS, the "service" element is

           nfs

   Implementations of security mechanisms will convert nfs@hostname to
   various different forms. For Kerberos V5 and LIPKEY, the following
   form is RECOMMENDED:

           nfs/hostname

   For Kerberos V5, nfs/hostname would be a server principal in the
   Kerberos Key Distribution Center database.  For LIPKEY, this would be
   the username passed to the target (the NFS version 4 client that
   receives the callback).

   It should be noted that LIPKEY may not work for callbacks, since the
   LIPKEY client uses a user id/password.  If the NFS client receiving
   the callback can authenticate the NFS server's user name/password
   pair, and if the user that the NFS server is authenticating to has a
   public key certificate, then it works.

   In situations where the NFS client uses LIPKEY and uses a per-host
   principal for the SETCLIENTID operation, instead of using LIPKEY for
   SETCLIENTID, it is RECOMMENDED that SPKM-3 with mutual authentication
   be used.  This effectively means that the client will use a
   certificate to authenticate and identify the initiator to the target
   on the NFS server.  Using SPKM-3 and not LIPKEY has the following
   advantages:

   o    When the server does a callback, it must authenticate to the
        principal used in the SETCLIENTID.  Even if LIPKEY is used,
        because LIPKEY is layered over SPKM-3, the NFS client will need
        to have a certificate that corresponds to the principal used in

Draft Specification      NFS version 4 Protocol                July 2002
        the SETCLIENTID operation.  From an administrative perspective,
        having a user name, password, and certificate for both the
        client and server is redundant.

   o    LIPKEY was intended to minimize additional infrastructure
        requirements beyond a certificate for the target, and the
        expectation is that existing password infrastructure can be
        leveraged for the initiator.  In some environments, a per-host
        password does not exist yet.  If certificates are used for any
        per-host principals, then additional password infrastructure is

Draft Specification      NFS version 4 Protocol              August 2002

        not needed.

   o    In cases when a host is both an NFS client and server, it can
        share the same per-host certificate.

Draft Specification      NFS version 4 Protocol                July              August 2002

4.  Filehandles

   The filehandle in the NFS protocol is a per server unique identifier
   for a file system filesystem object.  The contents of the filehandle are opaque
   to the client.  Therefore, the server is responsible for translating
   the filehandle to an internal representation of the file system
   object.  Since the filehandle is the client's reference to an object
   and the client may cache this reference, the server SHOULD not reuse
   a filehandle for another file system filesystem
   object.  If the server needs to
   reuse a filehandle value, the time elapsed before reuse SHOULD be
   large enough such that it is unlikely the client has a cached copy of
   the reused filehandle value.  Note that a client may cache a
   filehandle for a very long time.  For example, a client may cache NFS
   data to local storage as a method to expand its effective cache size
   and as a means to survive client restarts.  Therefore, the lifetime
   of a cached filehandle may be extended.

4.1.  Obtaining the First Filehandle

   The operations of the NFS protocol are defined in terms of one or
   more filehandles.  Therefore, the client needs a filehandle to
   initiate communication with the server.  With the NFS version 2
   protocol [RFC1094] and the NFS version 3 protocol [RFC1813], there
   exists an ancillary protocol to obtain this first filehandle.  The
   MOUNT protocol, RPC program number 100005, provides the mechanism of
   translating a string based file system filesystem path name to a filehandle which
   can then be used by the NFS protocols.

   The MOUNT protocol has deficiencies in the area of security and use
   via firewalls.  This is one reason that the use of the public
   filehandle was introduced in [RFC2054] and [RFC2055].  With the use
   of the public filehandle in combination with the LOOKUP procedure operation in
   the NFS version 2 and 3 protocols, it has been demonstrated that the
   MOUNT protocol is unnecessary for viable interaction between NFS
   client and server.

   Therefore, the NFS version 4 protocol will not use an ancillary
   protocol for translation from string based path names to a
   filehandle.  Two special filehandles will be used as starting points
   for the NFS client.

4.1.1.  Root Filehandle

   The first of the special filehandles is the ROOT filehandle.  The
   ROOT filehandle is the "conceptual" root of the file system filesystem name space
   at the NFS server.  The client uses or starts with the ROOT
   filehandle by employing the PUTROOTFH operation.  The PUTROOTFH
   operation instructs the server to set the "current" filehandle to the
   ROOT of the server's file tree.  Once this PUTROOTFH operation is
   used, the client can then traverse the entirety of the server's file

Draft Specification      NFS version 4 Protocol                July 2002
   tree with the LOOKUP procedure. operation.  A complete discussion of the server
   name space is in the section "NFS Server Name Space".

4.1.2.  Public Filehandle

   The second special filehandle is the PUBLIC filehandle.  Unlike the
   ROOT filehandle, the PUBLIC filehandle may be bound or represent an
   arbitrary file system filesystem object at the server.  The server is responsible

Draft Specification      NFS version 4 Protocol              August 2002

   for this binding.  It may be that the PUBLIC filehandle and the ROOT
   filehandle refer to the same file system filesystem object.  However, it is up to
   the administrative software at the server and the policies of the
   server administrator to define the binding of the PUBLIC filehandle
   and server file system filesystem object.  The client may not make any
   assumptions about this binding. The client uses the PUBLIC filehandle
   via the PUTPUBFH operation.

4.2.  Filehandle Types

   In the NFS version 2 and 3 protocols, there was one type of
   filehandle with a single set of semantics.  The NFS version 4
   protocol introduces a new type of filehandle in an attempt to
   accommodate certain server environments.  The first  This type of filehandle
   is 'persistent'. termed "persistent" in NFS Version 4.  The semantics of a
   persistent filehandle
   are remain the same as the filehandles of the NFS version 2 and 3 protocols.
   The second or before.  A new type of
   filehandle introduced in NFS Version 4 is the "volatile" filehandle. filehandle,
   which attempts to accommodate certain server environments.

   The volatile filehandle type is being was introduced to address server
   functionality or implementation issues which make correct
   implementation of a persistent filehandle infeasible.  Some server
   environments do not provide a file system filesystem level invariant that can be
   used to construct a persistent filehandle.  The underlying server
   file system
   filesystem may not provide the invariant or the server's file system filesystem
   programming interfaces may not provide access to the needed
   invariant.  Volatile filehandles may ease the implementation of
   server functionality such as hierarchical storage management or file
   system
   filesystem reorganization or migration.  However, the volatile
   filehandle increases the implementation burden for the client.  However this
   increased burden is deemed acceptable based on the overall gains
   achieved by the protocol.

   Since the client will need to handle persistent and volatile
   filehandle
   filehandles differently, a file attribute is defined which may be
   used by the client to determine the filehandle types being returned
   by the server.

4.2.1.  General Properties of a Filehandle

   The filehandle contains all the information the server needs to
   distinguish an individual file.  To the client, the filehandle is
   opaque. The client stores filehandles for use in a later request and

Draft Specification      NFS version 4 Protocol                July 2002
   can compare two filehandles from the same server for equality by
   doing a byte-by-byte comparison.  However, the client MUST NOT
   otherwise interpret the contents of filehandles.  If two filehandles
   from the same server are equal, they MUST refer to the same file.  If
   they are not equal, the client may use information provided by the
   server, in the form of file attributes, to determine whether they
   denote the same files or different files.  The client would do this
   as necessary for client side caching.
   Servers SHOULD try to maintain a one-to-one correspondence between
   filehandles and files but this is not required.  Clients MUST use
   filehandle comparisons only to improve performance, not for correct
   behavior.  All clients need to be prepared for situations in which it
   cannot be determined whether two filehandles denote the same object
   and in such cases, avoid making invalid assumpions which might cause
   incorrect behavior.  Further discussion of filehandle and attribute

Draft Specification      NFS version 4 Protocol              August 2002

   comparison in the context of data caching is presented in the section
   "Data Caching and File Identity".

   As an example, in the case that two different path names when
   traversed at the server terminate at the same file system filesystem object, the
   server SHOULD return the same filehandle for each path.  This can
   occur if a hard link is used to create two file names which refer to
   the same underlying file object and associated data.  For example, if
   paths /a/b/c and /a/d/c refer to the same file, the server SHOULD
   return the same filehandle for both path names traversals.

4.2.2.  Persistent Filehandle

   A persistent filehandle is defined as having a fixed value for the
   lifetime of the file system filesystem object to which it refers.  Once the
   server creates the filehandle for a file system filesystem object, the server
   MUST accept the same filehandle for the object for the lifetime of
   the object.  If the server restarts or reboots the NFS server must
   honor the same filehandle value as it did in the server's previous
   instantiation.  Similarly, if the file system filesystem is migrated, the new NFS
   server must honor the same file handle filehandle as the old NFS server.

   The persistent filehandle will be become stale or invalid when the
   file system
   filesystem object is removed.  When the server is presented with a
   persistent filehandle that refers to a deleted object, it MUST return
   an error of NFS4ERR_STALE.  A filehandle may become stale when the
   file system
   filesystem containing the object is no longer available.  The file
   system may become unavailable if it exists on removable media and the
   media is no longer available at the server or the file system filesystem in whole
   has been destroyed or the file system filesystem has simply been removed from the
   server's name space (i.e. unmounted in a Unix UNIX environment).

4.2.3.  Volatile Filehandle

   A volatile filehandle does not share the same longevity

Draft Specification      NFS version 4 Protocol                July 2002
   characteristics of a persistent filehandle.  The server may determine
   that a volatile filehandle is no longer valid at many different
   points in time.  If the server can definitively determine that a
   volatile filehandle refers to an object that has been removed, the
   server should return NFS4ERR_STALE to the client (as is the case for
   persistent filehandles).  In all other cases where the server
   determines that a volatile filehandle can no longer be used, it
   should return an error of NFS4ERR_FHEXPIRED.

   The mandatory attribute "fh_expire_type" is used by the client to
   determine what type of filehandle the server is providing for a
   particular file system. filesystem.  This attribute is a bitmask with the
   following values:

Draft Specification      NFS version 4 Protocol              August 2002

   FH4_PERSISTENT
        The value of FH4_PERSISTENT is used to indicate a persistent
        filehandle, which is valid until the object is removed from the
        file system.
        filesystem.  The server will not return NFS4ERR_FHEXPIRED for
        this filehandle.  FH4_PERSISTENT is defined as a value in which
        none of the bits specified below are set.

   FH4_NOEXPIRE_WITH_OPEN

   FH4_VOLATILE_ANY
        The filehandle will not may expire while client has the file open. at any time, except as specifically
        excluded (i.e. FH4_NO_EXPIRE_WITH_OPEN).

   FH4_NOEXPIRE_WITH_OPEN
        May only be set when FH4_VOLATILE_ANY is set.  If this bit is
        set, then the values meaning of FH4_VOLATILE_ANY or
        FH4_VOL_RENAME do not impact expiration while the file is open.
        Once the file is closed or if the FH4_NOEXPIRE_WITH_OPEN bit is
        false, the rest qualified to
        exclude any expiration of the volatile related bits apply.

   FH4_VOLATILE_ANY
        The filehandle may expire at any time and will expire during
        system migration and rename. when it is open.

   FH4_VOL_MIGRATION
        The filehandle will expire during file system as a result of migration.  May
        only be set if FH4_VOLATILE_ANY  If
        FH4_VOL_ANY is not set. set, FH4_VOL_MIGRATION is redundant.

   FH4_VOL_RENAME
        The filehandle may will expire due to a during rename.  This includes a
        rename by the requesting client or a rename by another any other client.
        May only be set if FH4_VOLATILE_ANY
        If FH4_VOL_ANY is not set. set, FH4_VOL_RENAME is redundant.

        Servers which provide volatile filehandles that may expire while
        open (i.e. if FH4_VOL_MIGRATION or FH4_VOL_RENAME is set or if
        FH4_VOLATILE_ANY is set and FH4_NOEXPIRE_WITH_OPEN not set),
        should deny a RENAME or REMOVE that would affect an OPEN file or of
        any of the components leading to the OPEN file.  In addition,
        the server should deny all RENAME or REMOVE requests during the
        grace or lease period upon server restart.

   The reader may be wondering why there are three FH4_VOL*

        Note that the bits and why
   FH4_VOLATILE_ANY is exclusive of FH4_VOL_MIGRATION and
   FH4_VOL_RENAME.  If the a filehandle is normally persistent but
   cannot persist across a file set migration, then the presence of the

Draft Specification      NFS version 4 Protocol                July 2002

   FH4_VOL_MIGRATION or FH4_VOL_RENAME tells allow
        the client to determine that it can
   treat the file handle as persistent for purposes of maintaining expiration has occurred whenever a
   file name to file handle cache, except for the
        specific event
   described by the bit.  However, FH4_VOLATILE_ANY tells occurs, without an explicit filehandle expiration
        error from the client
   that it should server.  FH4_VOL_ANY does not maintain such a cache for unopened files.  A provide this form
        of information. In situations where the server MUST will expire many,
        but not present all filehandles upon migration (e.g. all but those that
        are open), FH4_VOLATILE_ANY with FH4_VOL_MIGRATION or
   FH4_VOL_RENAME as (in this will lead to confusion.  FH4_VOLATILE_ANY
   implies that case with
        FH4_NOEXPIRE_WITH_OPEN) is a better choice since the file handle client may
        not assume that all filehandles will expire upon when migration or rename,
        occurs, and it is likely that additional expirations will occur
        (as a result of file CLOSE) that are separated in
   addition to other events. time from the
        migration event itself.

4.2.4.  One Method of Constructing a Volatile Filehandle

   As mentioned, in some instances a filehandle is stale (no longer
   valid; perhaps because the file was removed from the server) or it is
   expired (the underlying file is valid but since the filehandle is

Draft Specification      NFS version 4 Protocol              August 2002

   volatile, it may have expired).  Thus the server needs to be able to
   return NFS4ERR_STALE in the former case and NFS4ERR_FHEXPIRED in the
   latter case. This can be done by careful construction of the volatile
   filehandle.  One possible implementation follows.

   A volatile filehandle, while opaque to the client could contain:

   [volatile bit = 1 | server boot time | slot | generation number]

   o    slot is an index in the server volatile filehandle table

   o    generation number is the generation number for the table
        entry/slot

   If the server boot time is less than the current server boot time,
   return NFS4ERR_FHEXPIRED.  If slot is out of range, return
   NFS4ERR_BADHANDLE.  If the generation number does not match, return
   NFS4ERR_FHEXPIRED.

   When the server reboots, the table is gone (it is volatile).

   If volatile bit is 0, then it is a persistent filehandle with a
   different structure following it.

4.3.  Client Recovery from Filehandle Expiration

   If possible, the client SHOULD recover from the receipt of an
   NFS4ERR_FHEXPIRED error.  The client must take on additional
   responsibility so that it may prepare itself to recover from the
   expiration of a volatile filehandle.  If the server returns
   persistent filehandles, the client does not need these additional
   steps.

Draft Specification      NFS version 4 Protocol                July 2002

   For volatile filehandles, most commonly the client will need to store
   the component names leading up to and including the file system filesystem object
   in question.  With these names, the client should be able to recover
   by finding a filehandle in the name space that is still available or
   by starting at the root of the server's file system filesystem name space.

   If the expired filehandle refers to an object that has been removed
   from the file system, filesystem, obviously the client will not be able to recover
   from the expired filehandle.

   It is also possible that the expired filehandle refers to a file that
   has been renamed.  If the file was renamed by another client, again
   it is possible that the original client will not be able to recover.
   However, in the case that the client itself is renaming the file and
   the file is open, it is possible that the client may be able to
   recover.  The client can determine the new path name based on the
   processing of the rename request.  The client can then regenerate the

Draft Specification      NFS version 4 Protocol              August 2002

   new filehandle based on the new path name.  The client could also use
   the compound operation mechanism to construct a set of operations
   like:
           RENAME A B
           LOOKUP B
           GETFH
   Note that the COMPOUND procedure does not provide atomicity.  This
   example only reduces the overhead of recovering from an expired
   filehandle.

Draft Specification      NFS version 4 Protocol                July              August 2002

5.  File Attributes

   To meet the requirements of extensibility and increased
   interoperability with non-Unix non-UNIX platforms, attributes must be handled
   in a flexible manner.  The NFS Version version 3 fattr3 structure contains a
   fixed list of attributes that not all clients and servers are able to
   support or care about.  The fattr3 structure can not be extended as
   new needs arise and it provides no way to indicate non-support.  With
   the NFS Version version 4 protocol, the client will be is able to ask query what attributes
   the server supports and will be able to request construct requests with only those supported
   attributes in which it is interested. (or a subset thereof).

   To this end, attributes will be are divided into three groups: mandatory,
   recommended, and named.  Both mandatory and recommended attributes
   are supported in the NFS version 4 protocol by a specific and well-
   defined encoding and are identified by number.  They are requested by
   setting a bit in the bit vector sent in the GETATTR request; the
   server response includes a bit vector to list what attributes were
   returned in the response.  New mandatory or recommended attributes
   may be added to the NFS protocol between major revisions by
   publishing a standards-track RFC which allocates a new attribute
   number value and defines the encoding for the attribute.  See the
   section "Minor Versioning" for further discussion.

   Named attributes are accessed by the new OPENATTR operation, which
   accesses a hidden directory of attributes associated with a file
   system object.  OPENATTR takes a filehandle for the object and
   returns the filehandle for the attribute hierarchy.  The filehandle
   for the named attributes is a directory object accessible by LOOKUP
   or READDIR and contains files whose names represent the named
   attributes and whose data bytes are the value of the attribute.  For
   example:

          LOOKUP     "foo"       ; look up file
          GETATTR    attrbits
          OPENATTR               ; access foo's named attributes
          LOOKUP     "x11icon"   ; look up specific attribute
          READ       0,4096      ; read stream of bytes

   Named attributes are intended for data needed by applications rather
   than by an NFS client implementation.  NFS implementors are strongly
   encouraged to define their new attributes as recommended attributes
   by bringing them to the IETF standards-track process.

   The set of attributes which are classified as mandatory is
   deliberately small since servers must do whatever it takes to support
   them.  The recommended attributes may be unsupported; though a  A server should support as many of the recommended attributes
   as it can. possible but by their definition, the server is not required to
   support all of them.  Attributes are deemed mandatory if the data is
   both needed by a large number of clients and is not otherwise

Draft Specification      NFS version 4 Protocol              August 2002

   reasonably computable by the client when support is not

Draft Specification      NFS version 4 Protocol                July 2002 provided on
   the server.

   Note that the hidden directory returned by OPENATTR is a convenience
   for protocol processing.  The client should not make any assumptions
   about the server's implementation of named attributes and whether the
   underlying filesystem at the server has a named attribute directory
   or not.  Therefore, operations such as SETATTR and GETATTR on the
   named attribute directory are undefined.

5.1.  Mandatory Attributes

   These MUST be supported by every NFS Version version 4 client and server in
   order to ensure a minimum level of interoperability.  The server must
   store and return these attributes and the client must be able to
   function with an attribute set limited to these attributes.  With
   just the mandatory attributes some client functionality may be
   impaired or limited in some ways.  A client may ask for any of these
   attributes to be returned by setting a bit in the GETATTR request and
   the server must return their value.

5.2.  Recommended Attributes

   These attributes are understood well enough to warrant support in the
   NFS Version version 4 protocol.  However, they may not be supported on all
   clients and servers.  A client may ask for any of these attributes to
   be returned by setting a bit in the GETATTR request but must handle
   the case where the server does not return them.  A client may ask for
   the set of attributes the server supports and should not request
   attributes the server does not support.  A server should be tolerant
   of requests for unsupported attributes and simply not return them
   rather than considering the request an error.  It is expected that
   servers will support all attributes they comfortably can and only
   fail to support attributes which are difficult to support in their
   operating environments.  A server should provide attributes whenever
   they don't have to "tell lies" to the client.  For example, a file
   modification time should be either an accurate time or should not be
   supported by the server.  This will not always be comfortable to
   clients but it seems that the client has a is better ability to
   fabricate or positioned decide whether and how to
   fabricate or construct an attribute or whether to do without the
   attribute.

5.3.  Named Attributes

   These attributes are not supported by direct encoding in the NFS
   Version 4 protocol but are accessed by string names rather than
   numbers and correspond to an uninterpreted stream of bytes which are
   stored with the file system filesystem object.  The name space for these

Draft Specification      NFS version 4 Protocol              August 2002

   attributes may be accessed by using the OPENATTR operation.  The
   OPENATTR operation returns a filehandle for a virtual "attribute
   directory" and further perusal of the name space may be done using
   READDIR and LOOKUP operations on this filehandle.  Named attributes
   may then be examined or changed by normal READ and WRITE and CREATE
   operations on the filehandles returned from READDIR and LOOKUP.
   Named attributes may have attributes.

   It is recommended that servers support arbitrary named attributes.  A
   client should not depend on the ability to store any named attributes

Draft Specification      NFS version 4 Protocol                July 2002
   in the server's file system. filesystem.  If a server does support named
   attributes, a client which is also able to handle them should be able
   to copy a file's data and meta-data with complete transparency from
   one location to another; this would imply that names allowed for
   regular directory entries are valid for named attribute names as
   well.

   Names of attributes will not be controlled by this document or other
   IETF standards track documents.  See the section "IANA
   Considerations" for further discussion.

5.4.  Classification of Attributes

   Each of the Mandatory and Recommended attributes can be classified in
   one of three categories: per server, per filesystem, or per
   filesystem object.  Note that it is possible that some per filesystem
   attributes may vary within the filesystem.  See the "homogeneous"
   attribute for its definition.  Note that the attributes
   time_access_set and time_modify_set are not listed below because they
   are write-only attributes used in a special instance of SETATTR.

   o    The per server attribute is:

        lease_time

   o    The per filesystem attributes are:

        supp_attr, fh_expire_type, link_support, symlink_support,
        unique_handles, aclsupport, cansettime, case_insensitive,
        case_preserving, chown_restricted, files_avail, files_free,
        files_total, fs_locations, homogeneous, maxfilesize, maxname,
        maxread, maxwrite, no_trunc, space_avail, space_free,
        space_total, time_delta

   o    The per filesystem object attributes are:

        type, change, size, named_attr, fsid, rdattr_error, filehandle,
        ACL, archive, fileid, hidden, maxlink, mimetype, mode, numlinks,
        owner, owner_group, rawdev, space_used, system, time_access,
        time_backup, time_create, time_metadata, time_modify,
        mounted_on_fileid

Draft Specification      NFS version 4 Protocol                July              August 2002

5.4.

   For quota_avail_hard, quota_avail_soft, and quota_used see their
   definitions below for the appropriate classification.

Draft Specification      NFS version 4 Protocol              August 2002

5.5.  Mandatory Attributes - Definitions

   Name              #    DataType     Access   Description
   ___________________________________________________________________
   supp_attr         0    bitmap       READ     The bit vector which
                                                would retrieve all
                                                mandatory and
                                                recommended attributes
                                                that are supported for
                                                this object.  The
                                                scope of this
                                                attribute applies to
                                                all objects with a
                                                matching fsid.

   type              1    nfs4_ftype   READ     The type of the object
                                                (file, directory,
                                                symlink)
                                                symlink, etc.)

   fh_expire_type    2    uint32       READ     Server uses this to
                                                specify filehandle
                                                expiration behavior to
                                                the client.  See the
                                                section "Filehandles"
                                                for additional
                                                description.

   change            3    uint64       READ     A value created by the
                                                server that the client
                                                can use to determine
                                                if file data,
                                                directory contents or
                                                attributes of the
                                                object have been
                                                modified.  The server
                                                may return the
                                                object's time_modify time_metadata
                                                attribute for this
                                                attribute's value but
                                                only if the file
                                                system filesystem
                                                object can not be
                                                updated more
                                                frequently than the
                                                resolution of
                                                time_modify.
                                                time_metadata.

   size              4    uint64       R/W
                                                The size of the object
                                                in bytes.

Draft Specification      NFS version 4 Protocol              August 2002

   link_support      5    bool         READ
                                                Does     True, if the object's file
                                                system
                                                filesystem supports
                                                hard
                                                links?

Draft Specification      NFS version 4 Protocol                July 2002 links.

   symlink_support   6    bool         READ
                                                Does     True, if the object's file
                                                system
                                                filesystem supports
                                                symbolic links? links.

   named_attr        7    bool         READ
                                                Does     True, if this object have
                                                has named attributes.
                                                In other words, object
                                                has a non-empty named attributes?
                                                attribute directory.

   fsid              8    fsid4        READ     Unique file system filesystem
                                                identifier for the
                                                file system
                                                filesystem holding
                                                this object.  fsid
                                                contains major and
                                                minor components each
                                                of which are uint64.

   unique_handles    9    bool         READ
                                                Are
                                                True, if two distinct
                                                filehandles guaranteed
                                                to refer to two
                                                different file system
                                                objects? filesystem
                                                objects.

   lease_time        10   nfs_lease4   READ     Duration of leases at
                                                server in seconds.

   rdattr_error      11   enum         READ     Error returned from
                                                getattr during
                                                readdir.

   filehandle        19   nfs_fh4      READ     The filehandle of this
                                                object (primarily for
                                                readdir requests).

Draft Specification      NFS version 4 Protocol                July              August 2002

5.5.

5.6.  Recommended Attributes - Definitions

 Name                #    Data Type      Access   Description
   _____________________________________________________________________
 ______________________________________________________________________
 ACL                 12   nfsace4<>      R/W      The access control
                                                  list for the object.

 aclsupport          13   uint32         READ     Indicates what types
                                                  of ACLs are supported
                                                  on the current file
                                                   system.
                                                  filesystem.

 archive             14   bool           R/W
                                                   Whether or not      True, if this file
                                                  has been archived
                                                  since the time of
                                                  last modification
                                                  (deprecated in favor
                                                  of time_backup).

 cansettime          15   bool           READ
                                                   Is     True, if the server
                                                  able to change the
                                                  times for a file system
                                                  filesystem object as
                                                  specified in a
                                                  SETATTR operation? operation.

 case_insensitive    16   bool           READ
                                                   Are     True, if filename
                                                  comparisons on this
                                                   file system
                                                  filesystem case
                                                   insensitive?
                                                  insensitive.

 case_preserving     17   bool           READ
                                                   Is     True, if filename
                                                  case on this file system
                                                   preserved?
                                                  filesystem preserved.

 chown_restricted    18   bool           READ     If TRUE, the server
                                                  will reject any
                                                  request to change
                                                  either the owner or
                                                  the group associated
                                                  with a file if the
                                                  caller is not a
                                                  privileged user (for
                                                  example, "root" in
                                                   Unix
                                                  UNIX operating
                                                  environments or in NT
                                                  Windows 2000 the
                                                  "Take Ownership"
                                                   privilege)
                                                  privilege).

Draft Specification      NFS version 4 Protocol                July              August 2002

 fileid              20   uint64         READ     A number uniquely
                                                  identifying the file
                                                  within the file
                                                   system.
                                                  filesystem.

 files_avail         21   uint64         READ     File slots available
                                                  to this user on the
                                                   file system
                                                  filesystem containing
                                                  this object - this
                                                  should be the
                                                  smallest relevant
                                                  limit.

 files_free          22   uint64         READ     Free file slots on
                                                  the file system filesystem
                                                  containing this
                                                  object - this should
                                                  be the smallest
                                                  relevant limit.

 files_total         23   uint64         READ     Total file slots on
                                                  the file system filesystem
                                                  containing this
                                                  object.

 fs_locations        24   fs_locations   READ     Locations where this
                                                   file system
                                                  filesystem may be
                                                  found.  If the server
                                                  returns NFS4ERR_MOVED
                                                  as an error, this
                                                  attribute must MUST be
                                                  supported.

 hidden              25   bool           R/W
                                                   Is      True, if the file is
                                                  considered hidden
                                                  with respect to the WIN32
                                                  Windows API?

 homogeneous         26   bool           READ
                                                   Whether or not     True, if this
                                                  object's file system filesystem
                                                  is homogeneous, i.e.
                                                  are per file system filesystem
                                                  attributes the same
                                                  for all file system's filesystem's
                                                  objects.

 maxfilesize         27   uint64         READ     Maximum supported
                                                  file size for the
                                                   file system
                                                  filesystem of this
                                                  object.

Draft Specification      NFS version 4 Protocol                July              August 2002

 maxlink             28   uint32         READ     Maximum number of
                                                  links for this
                                                  object.

 maxname             29   uint32         READ     Maximum filename size
                                                  supported for this
                                                  object.

 maxread             30   uint64         READ     Maximum read size
                                                  supported for this
                                                  object.

 maxwrite            31   uint64         READ
                                                  Maximum write size
                                                  supported for this
                                                  object.  This
                                                  attribute SHOULD be
                                                  supported if the file
                                                  is writable.  Lack of
                                                  this attribute can
                                                  lead to the client
                                                  either wasting
                                                  bandwidth or not
                                                  receiving the best
                                                  performance.

 mimetype            32   utf8<>         R/W      MIME body
                                                  type/subtype of this
                                                  object.

 mode                33   mode4          R/W
                                                   Unix-style      UNIX-style mode and
                                                  permission bits for
                                                  this object
                                                   (deprecated in favor
                                                   of ACLs) object.

 no_trunc            34   bool           READ
                                                   If     True, if a name
                                                  longer than name_max
                                                  is used,
                                                   will an error be
                                                  returned or will the and name be truncated? is
                                                  not truncated.

 numlinks            35   uint32         READ     Number of hard links
                                                  to this object.

 owner               36   utf8<>         R/W      The string name of
                                                  the owner of this
                                                  object.

 owner_group         37   utf8<>         R/W      The string name of
                                                  the group ownership
                                                  of this object.

Draft Specification      NFS version 4 Protocol                July              August 2002

 quota_avail_hard    38   uint64         READ     For definition see
                                                  "Quota Attributes"
                                                  section below.

 quota_avail_soft    39   uint64         READ     For definition see
                                                  "Quota Attributes"
                                                  section below.

 quota_used          40   uint64         READ     For definition see
                                                  "Quota Attributes"
                                                  section below.

 rawdev              41   specdata4      READ     Raw device
                                                  identifier.  Unix  UNIX
                                                  device major/minor
                                                  node information.  If
                                                  the value of type is
                                                  not NF4BLK or NF4CHR,
                                                  the value return
                                                  SHOULD NOT be
                                                  considered useful.

 space_avail         42   uint64         READ     Disk space in bytes
                                                  available to this
                                                  user on the file
                                                   system
                                                  filesystem containing
                                                  this object - this
                                                  should be the
                                                  smallest relevant
                                                  limit.

 space_free          43   uint64         READ     Free disk space in
                                                  bytes on the file
                                                   system
                                                  filesystem containing
                                                  this object - this
                                                  should be the
                                                  smallest relevant
                                                  limit.

 space_total         44   uint64         READ     Total disk space in
                                                  bytes on the file
                                                   system
                                                  filesystem containing
                                                  this object.

 space_used          45   uint64         READ     Number of file system filesystem
                                                  bytes allocated to
                                                  this object.

Draft Specification      NFS version 4 Protocol              August 2002

 system              46   bool           R/W
                                                   Is      True, if this file is
                                                  a system "system" file with
                                                  respect to the WIN32
                                                  Windows API?

 time_access         47   nfstime4       READ     The time of last
                                                  access to the object.

Draft Specification      NFS version 4 Protocol                July 2002 object
                                                  by a read that was
                                                  satisfied by the
                                                  server.

 time_access_set     48   settime4       WRITE    Set the time of last
                                                  access to the object.
                                                  SETATTR use only.

 time_backup         49   nfstime4       R/W      The time of last
                                                  backup of the object.

 time_create         50   nfstime4       R/W
                                                  The time of creation
                                                  of the object. This
                                                  attribute does not
                                                  have any relation to
                                                  the traditional Unix UNIX
                                                  file attribute
                                                  "ctime" or "change
                                                  time".

 time_delta          51   nfstime4       READ     Smallest useful
                                                  server time
                                                  granularity.

 time_metadata       52   nfstime4       R/W      The time of last
                                                  meta-data
                                                  modification of the
                                                  object.

 time_modify         53   nfstime4       READ     The time of last
                                                  modification to the
                                                  object.

 time_modify_set     54   settime4       WRITE    Set the time of last
                                                  modification to the
                                                  object.  SETATTR use
                                                  only.

5.6.  Interpreting owner and owner_group

   The recommended attributes "owner" and "owner_group" (and also users
   and groups within

 mounted_on_fileid   55   uint64         READ     Like fileid, but if
                                                  the "acl" attribute) are represented in terms of a
   UTF-8 string.  To avoid a representation that target filehandle
                                                  is tied to the root of a particular
                                                  filesystem return the
                                                  fileid of the
                                                  underlying implementation at directory.

Draft Specification      NFS version 4 Protocol              August 2002

5.7.  Time Access

   As defined above, the client or server, time_access attribute represents the use time of
   last access to the
   UTF-8 string has been chosen.  Note that section 6.1 of [RFC2624]
   provides additional rationale.  It is expected object by a read that was satisfied by the client and
   server will have their own local representation server.
   The notion of owner and
   owner_group that what is used for local storage or presentation to an "access" depends on server's operating
   environment and/or the end
   user.  Therefore, it is server's filesystem semantics.  For example,
   for servers obeying POSIX semantics, time_access would be updated
   only by the READLINK, READ, and READDIR operations and not any of the
   operations that modify the content of the object. Of course, setting
   the corresponding time_access_set attribute is another way to modify
   the time_access attribute.

   Whenever the file object resides on a writeable filesystem, the
   server should make best efforts to record time_access into stable
   storage.  However, to mitigate the performance effects of doing so,
   and most especially whenever the server is satisifying the read of
   the object's content from its cache, the server MAY cache access time
   updates and lazily write them to stable storage.  It is also
   acceptable to give administrators of the server the option to disable
   time_access updates.

5.8.  Interpreting owner and owner_group

   The recommended attributes "owner" and "owner_group" (and also users
   and groups within the "acl" attribute) are represented in terms of a
   UTF-8 string.  To avoid a representation that is tied to a particular
   underlying implementation at the client or server, the use of the
   UTF-8 string has been chosen.  Note that section 6.1 of [RFC2624]
   provides additional rationale.  It is expected that the client and
   server will have their own local representation of owner and
   owner_group that is used for local storage or presentation to the end
   user.  Therefore, it is expected that when these attributes are
   transferred between the client and server that the local
   representation is translated to a syntax of the form
   "user@dns_domain".  This will allow for a client and server that do
   not use the same local representation the ability to translate to a
   common syntax that can be interpreted by both.

Draft Specification      NFS version 4 Protocol                July 2002

   Similarly, security principals may be represented in different ways
   by different security mechanisms.  Servers normally translate these
   representations into a common format, generally that used by local
   storage, to serve as a means of identifying the users corresponding
   to these security principals.  When these local identifiers are
   translated to the form of the owner attribute, associated with files
   created by such principals they identify, in a common format, the
   users associated with each corresponding set of security principals.

   The translation used to interpret owner and group strings is not
   specified as part of the protocol.  This allows various solutions to
   be employed.  For example, a local translation table may be consulted
   that maps between a numeric id to the user@dns_domain syntax.  A name

Draft Specification      NFS version 4 Protocol              August 2002

   service may also be used to accomplish the translation.  A server may
   provide a more general service, not limited by any particular
   translation (which would only translate a limited set of possible
   strings) by storing the owner and owner_group attributes in local
   storage without any translation or it may augment a translation
   method by storing the entire string for attributes for which no
   translation is available while using the local representation for
   those cases in which a translation is available.

   Servers that do not provide support for all possible values of the
   owner and owner_group attributes, should return an error
   (NFS4ERR_BADOWNER) when a string is presented that has no
   translation, as the value to be set for a SETATTR of the owner,
   owner_group, or acl attributes.  When a server does accept an owner
   or owner_group value as valid on a SETATTR (and similarly for the
   owner and group strings in an acl), it is promising to return that
   same string when a corresponding GETATTR is done.  Configuration
   changes and ill-constructed name translations (those that contain
   aliasing) may make that promise impossible to honor.  Servers should
   make appropriate efforts to avoid a situation in which these
   attributes have their values changed when no real change to ownership
   has occurred.

   The "dns_domain" portion of the owner string is meant to be a DNS
   domain name.  For example, user@ietf.org.  Servers should accept as
   valid a set of users for at least one domain.  A server may treat
   other domains as having no valid translations.  A more general
   service is provided when a server is capable of accepting users for
   multiple domains, or for all domains, subject to security
   constraints.

   In the case where there is no translation available to the client or
   server, the attribute value must be constructed without the "@".
   Therefore, the absence of the @ from the owner or owner_group
   attribute signifies that no translation was available at the sender
   and that the receiver of the attribute should not use that string as
   a basis for translation into its own internal format.  Even though
   the attribute value can not be translated, it may still be useful.
   In the case of a client, the attribute string may be used for local

Draft Specification      NFS version 4 Protocol                July 2002
   display of ownership.

   To provide a greater degree of compatibility with previous versions
   of NFS (i.e. v2 and v3), which identified users and groups by 32-bit
   unsigned uid's and gid's, owner and group strings that consist of
   decimal numeric values with no leading zeros can be given a special
   interpretation by clients and servers which choose to provide such
   support.  The receiver may treat such a user or group string as
   representing the same user as would be represented by a v2/v3 uid or
   gid having the corresponding numeric value.  A server is not
   obligated to accept such a string, but may return an NFS4ERR_BADOWNER
   instead.  To avoid this mechanism being used to subvert user and
   group translation, so that a client might pass all of the owners and

Draft Specification      NFS version 4 Protocol              August 2002

   groups in numeric form, a server SHOULD return an NFS4ERR_BADOWNER
   error when there is a valid translation for the user or owner
   designated in this way.  In that case, the client must use the
   appropriate name@domain string and not the special form for
   compatibility.

   The owner string "nobody" may be used to designate an anonymous user,
   which will be associated with a file created by a security principal
   that cannot be mapped through normal means to the owner attribute.

5.7.

5.9.  Character Case Attributes

   With respect to the case_insensitive and case_preserving attributes,
   each UCS-4 character (which UTF-8 encodes) has a "long descriptive
   name" [RFC1345] which may or may not included the word "CAPITAL" or
   "SMALL".  The presence of SMALL or CAPITAL allows an NFS server to
   implement unambiguous and efficient table driven mappings for case
   insensitive comparisons, and non-case-preserving storage.  For
   general character handling and internationalization issues, see the
   section "Internationalization".

5.8.

5.10.  Quota Attributes

   For the attributes related to file system filesystem quotas, the following
   definitions apply:

   quota_avail_soft
        The value in bytes which represents the amount of additional
        disk space that can be allocated to this file or directory
        before the user may reasonably be warned.  It is understood that
        this space may be consumed by allocations to other files or
        directories though there is a rule as to which other files or
        directories.

   quota_avail_hard
        The value in bytes which represent the amount of additional disk

Draft Specification      NFS version 4 Protocol                July 2002
        space beyond the current allocation that can be allocated to
        this file or directory before further allocations will be
        refused.  It is understood that this space may be consumed by
        allocations to other files or directories.

   quota_used
        The value in bytes which represent the amount of disc space used
        by this file or directory and possibly a number of other similar
        files or directories, where the set of "similar" meets at least
        the criterion that allocating space to any file or directory in
        the set will reduce the "quota_avail_hard" of every other file
        or directory in the set.

Draft Specification      NFS version 4 Protocol              August 2002

        Note that there may be a number of distinct but overlapping sets
        of files or directories for which a quota_used value is
        maintained. E.g. "all files with a given owner", "all files with
        a given group owner". etc.

        The server is at liberty to choose any of those sets but should
        do so in a repeatable way.  The rule may be configured per-
        filesystem or may be "choose the set with the smallest quota".

5.9.

5.11.  Access Control Lists

   The NFS version 4 ACL attribute is an array of access control entries
   (ACE).  There are various access control entry types. types, as defined in
   the Section "ACE type".  The server is able to communicate which ACE
   types are supported by returning the appropriate value within the
   aclsupport attribute.  The types of ACEs
   are defined as follows:

   Type         Description
   _____________________________________________________
   ALLOW
                Explicitly grants the access defined in
                acemask4 to the file or directory.

   DENY
                Explicitly denies the access defined in
                acemask4 to the file  Each ACE covers one or directory.

   AUDIT
                LOG (system dependent) any access
                attempt to more operations on a
   file or directory which
                uses any of the access methods specified as described in acemask4.

   ALARM
                Generate a system ALARM (system
                dependent) when any access attempt is
                made to a file the Section "ACE Access Mask".  It
   may also contain one or directory for more flags that modify the
                access methods specified semantics of the
   ACE as defined in acemask4. the Section "ACE flag".

   The NFS ACE attribute is defined as follows:

Draft Specification      NFS version 4 Protocol                July 2002

        typedef uint32_t        acetype4;
        typedef uint32_t        aceflag4;
        typedef uint32_t        acemask4;

        struct nfsace4 {
                acetype4        type;
                aceflag4        flag;
                acemask4        access_mask;
                utf8string      who;
        };

   To determine if an ACCESS or OPEN a request succeeds succeeds, each nfsace4 entry is processed
   in order by the server.  Only ACEs which have a "who" that matches
   the requester are considered.  Each ACE is processed until all of the
   bits of the requester's access have been ALLOWED.  Once a bit (see
   below) has been ALLOWED by an ACCESS_ALLOWED_ACE, it is no longer
   considered in the processing of later ACEs. If an ACCESS_DENIED_ACE
   is encountered where the requester's mode access still has unALLOWED bits
   in common with the "access_mask" of the ACE, the request is denied.

   The bitmask constants used to represent
   However, unlike the above definitions within ALLOWED and DENIED ACE types, the aclsupport attribute ALARM and AUDIT
   ACE types do not affect a requestor's access, and instead are for
   triggering events as follows:

   const ACL4_SUPPORT_ALLOW_ACL    = 0x00000001;
   const ACL4_SUPPORT_DENY_ACL     = 0x00000002;
   const ACL4_SUPPORT_AUDIT_ACL    = 0x00000004;
   const ACL4_SUPPORT_ALARM_ACL    = 0x00000008;

5.9.1.  ACE type

   The semantics a result of a requestor's access attempt.
   Therefore, all AUDIT and ALARM ACEs are processed until end of the "type" field follow the descriptions provided
   above.
   ACL.

   The bitmask constants used for NFS version 4 ACL model is quite rich.  Some server platforms may
   provide access control functionality that goes beyond the type field are UNIX-style

Draft Specification      NFS version 4 Protocol              August 2002

   mode attribute, but which is not as rich as follows:

   const ACE4_ACCESS_ALLOWED_ACE_TYPE      = 0x00000000;
   const ACE4_ACCESS_DENIED_ACE_TYPE       = 0x00000001;
   const ACE4_SYSTEM_AUDIT_ACE_TYPE        = 0x00000002;
   const ACE4_SYSTEM_ALARM_ACE_TYPE        = 0x00000003;

5.9.2.  ACE flag

   The "flag" field contains values based on the following descriptions.

   ACE4_FILE_INHERIT_ACE

   Can be placed on a directory and indicates NFS ACL model.  So
   that users can take advantage of this ACE should be
   added to each new non-directory file created.

Draft Specification more limited functionality, the
   server may indicate that it supports ACLs as long as it follows the
   guidelines for mapping between its ACL model and the NFS version 4 Protocol                July 2002

   ACE4_DIRECTORY_INHERIT_ACE

   Can be placed on
   ACL model.

   The situation is complicated by the fact that a directory and indicates server may have
   multiple modules that this ACE should enforce ACLs.  For example, the enforcement for
   NFS version 4 access may be
   added to each new directory created.

   ACE4_INHERIT_ONLY_ACE

   Can different from the enforcement for local
   access, and both may be placed on a directory but does not apply to different from the directory,
   only to newly created files/directories enforcement for access
   through other protocols such as specified by the above two
   flags.

   ACE4_NO_PROPAGATE_INHERIT_ACE

   Can SMB.  So it may be placed on a directory. Normally when useful for a new directory is
   created and
   server to accept an ACE exists on the parent directory which is marked
   ACL4_DIRECTORY_INHERIT_ACE, two ACEs ACL even if not all of its modules are placed on the new directory.
   One for the directory itself and one which able to
   support it.

   The guiding principle in all cases is an inheritable ACE for
   newly created directories.  This flag tells that the server to must not place
   an accept
   ACLs that appear to make the file more secure than it really is.

5.11.1.  ACE on type

   Type         Description
   _____________________________________________________
   ALLOW        Explicitly grants the newly created directory which is inheritable by
   subdirectories of access defined in
                acemask4 to the created file or directory.

   ACE4_SUCCESSFUL_ACCESS_ACE_FLAG

   ACL4_FAILED_ACCESS_ACE_FLAG

   Both indicate for AUDIT and ALARM which state

   DENY         Explicitly denies the access defined in
                acemask4 to log the event.  On
   every ACCESS file or OPEN call which occurs on directory.

   AUDIT        LOG (system dependent) any access
                attempt to a file or directory which
   has an ACL that is
                uses any of type ACE4_SYSTEM_AUDIT_ACE_TYPE or
   ACE4_SYSTEM_ALARM_ACE_TYPE, the attempted access is compared to the
   ace4mask of these ACLs. If the methods specified
                in acemask4.

   ALARM        Generate a system ALARM (system
                dependent) when any access attempt is
                made to a subset of ace4mask and the
   identifier match, an AUDIT trail file or an ALARM is generated.  By
   default this happens regardless of directory for the success or failure
                access methods specified in acemask4.

   A server need not support all of the
   ACCESS or OPEN call.

   The flag ACE4_SUCCESSFUL_ACCESS_ACE_FLAG only produces the AUDIT or
   ALARM if the ACCESS or OPEN call is successful. The
   ACE4_FAILED_ACCESS_ACE_FLAG causes the ALARM or AUDIT if the ACCESS
   or OPEN call fails.

   ACE4_IDENTIFIER_GROUP

   Indicates that the "who" refers to a GROUP as defined under Unix. above ACE types.  The bitmask
   constants used for to represent the flag field above definitions within the
   aclsupport attribute are as follows:

        const ACE4_FILE_INHERIT_ACE ACL4_SUPPORT_ALLOW_ACL    = 0x00000001;

Draft Specification      NFS version 4 Protocol                July 2002
        const ACE4_DIRECTORY_INHERIT_ACE ACL4_SUPPORT_DENY_ACL     = 0x00000002;
        const ACE4_NO_PROPAGATE_INHERIT_ACE ACL4_SUPPORT_AUDIT_ACL    = 0x00000004;
        const ACE4_INHERIT_ONLY_ACE ACL4_SUPPORT_ALARM_ACL    = 0x00000008;

   The semantics of the "type" field follow the descriptions provided

Draft Specification      NFS version 4 Protocol              August 2002

   above.

   The constants used for the type field (acetype4) are as follows:

        const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG ACE4_ACCESS_ALLOWED_ACE_TYPE      = 0x00000010; 0x00000000;
        const ACE4_FAILED_ACCESS_ACE_FLAG ACE4_ACCESS_DENIED_ACE_TYPE       = 0x00000020; 0x00000001;
        const ACE4_IDENTIFIER_GROUP ACE4_SYSTEM_AUDIT_ACE_TYPE        = 0x00000040;

5.9.3. 0x00000002;
        const ACE4_SYSTEM_ALARM_ACE_TYPE        = 0x00000003;

   Clients should not attempt to set an ACE Access Mask

   The access_mask field contains values based on unless the server claims
   support for that ACE type.  If the server receives a request to set
   an ACE that it cannot store, it must reject the request with
   NFS4ERR_ATTRNOTSUPP.

   If the server receives a request to set an ACE that it can store but
   cannot enforce, the server SHOULD reject the request.

   Example: suppose a server can enforce NFS ACLs for NFS access but
   cannot enforce ACLs for local access.  If arbitrary processes can run
   on the server, then the server SHOULD NOT indicate ACL support.  On
   the other hand, if only trusted administrative programs run locally,
   then the server may indicate ACL support.

5.11.2.  ACE Access Mask

   The access_mask field contains values based on the following:

   Access                 Description
   _______________________________________________________________
   READ_DATA              Permission to read the data of the file
   LIST_DIRECTORY         Permission to list the contents of a
                          directory
   WRITE_DATA             Permission to modify the file's data
   ADD_FILE               Permission to add a new file to a
                          directory
   APPEND_DATA            Permission to append data to a file
   ADD_SUBDIRECTORY       Permission to create a subdirectory to a
                          directory
   READ_NAMED_ATTRS       Permission to read the named attributes
                          of a file
   WRITE_NAMED_ATTRS      Permission to write the named attributes
                          of a file
   EXECUTE                Permission to execute a file
   DELETE_CHILD           Permission to delete a file or directory
                          within a directory
   READ_ATTRIBUTES        The ability to read basic attributes
                          (non-acls) of a file

Draft Specification      NFS version 4 Protocol              August 2002

   WRITE_ATTRIBUTES       Permission to change basic attributes
                          (non-acls) of a file

   DELETE                 Permission to Delete the file
   READ_ACL               Permission to Read the ACL
   WRITE_ACL              Permission to Write the ACL
   WRITE_OWNER            Permission to change the owner
   SYNCHRONIZE            Permission to access file locally at the
                          server with synchronous reads and writes

   The bitmask constants used for the access mask field are as follows:

   const ACE4_READ_DATA            = 0x00000001;
   const ACE4_LIST_DIRECTORY       = 0x00000001;
   const ACE4_WRITE_DATA           = 0x00000002;
   const ACE4_ADD_FILE             = 0x00000002;
   const ACE4_APPEND_DATA          = 0x00000004;
   const ACE4_ADD_SUBDIRECTORY     = 0x00000004;
   const ACE4_READ_NAMED_ATTRS     = 0x00000008;

Draft Specification      NFS version 4 Protocol                July 2002
   const ACE4_WRITE_NAMED_ATTRS    = 0x00000010;
   const ACE4_EXECUTE              = 0x00000020;
   const ACE4_DELETE_CHILD         = 0x00000040;
   const ACE4_READ_ATTRIBUTES      = 0x00000080;
   const ACE4_WRITE_ATTRIBUTES     = 0x00000100;
   const ACE4_DELETE               = 0x00010000;
   const ACE4_READ_ACL             = 0x00020000;
   const ACE4_WRITE_ACL            = 0x00040000;
   const ACE4_WRITE_OWNER          = 0x00080000;
   const ACE4_SYNCHRONIZE          = 0x00100000;

5.9.4.  ACE who

   There are several special identifiers ("who") which

   Server implementations need to be
   understood universally. Some of these identifiers cannot be
   understood when an NFS client accesses not provide the server, but have meaning
   when granularity of control
   that is implied by this list of masks.  For example, POSIX-based
   systems might not distinguish APPEND_DATA (the ability to append to a local process accesses the file. The
   file) from WRITE_DATA (the ability to display and modify these permissions is permitted over NFS.

   Who                    Description
   _______________________________________________________________
   "OWNER"
                          The owner of the file.
   "GROUP"
                          The group associated with the file.
   "EVERYONE"
                          The world.
   "INTERACTIVE"
                          Accessed from an interactive terminal.
   "NETWORK"
                          Accessed via the network.
   "DIALUP"
                          Accessed as existing contents); both
   masks would be tied to a dialup user single ``write'' permission.  When such a
   server returns attributes to the server.
   "BATCH"
                          Accessed from client, it would show both
   APPEND_DATA and WRITE_DATA if and only if the write permission is
   enabled.

   If a batch job.
   "ANONYMOUS"
                          Accessed without any authentication.
   "AUTHENTICATED"
                          Any authenticated user (opposite server receives a SETATTR request that it cannot accurately
   implement, it should error in the direction of
                          ANONYMOUS)
   "SERVICE"
                          Access from more restricted
   access.  For example, suppose a system service.

   To avoid conflict, these special identifiers are server cannot distinguish by overwriting
   data from appending new data, as described in the previous paragraph.
   If a client submits an
   appended "@" and ACE where APPEND_DATA is set but WRITE_DATA is
   not (or vice versa), the server should appear in reject the form "xxxx@" (note: no domain
   name after request with
   NFS4ERR_ATTRNOTSUPP.  Nonetheless, if the "@").  For example: ANONYMOUS@. ACE has type DENY, the
   server may silently turn on the other bit, so that both APPEND_DATA
   and WRITE_DATA are denied.

Draft Specification      NFS version 4 Protocol                July              August 2002

6.  File System Migration and Replication

   With the use of the recommended attribute "fs_locations",

5.11.3.  ACE flag

   The "flag" field contains values based on the NFS
   version 4 server has following descriptions.

   ACE4_FILE_INHERIT_ACE

   Can be placed on a method of providing file system migration or
   replication services.  For the purposes of migration directory and replication,
   a indicates that this ACE should be
   added to each new non-directory file system will created.

   ACE4_DIRECTORY_INHERIT_ACE

   Can be defined as all files that share placed on a given fsid
   (both major directory and minor values are the same).

   The fs_locations attribute provides indicates that this ACE should be
   added to each new directory created.

   ACE4_INHERIT_ONLY_ACE

   Can be placed on a list of file system locations.
   These locations are directory but does not apply to the directory,
   only to newly created files/directories as specified by providing the server name (either
   DNS domain or IP address) and the path name representing the root of
   the file system.  Depending above two
   flags.

   ACE4_NO_PROPAGATE_INHERIT_ACE

   Can be placed on a directory. Normally when a new directory is
   created and an ACE exists on the type of service being provided, parent directory which is marked
   ACL4_DIRECTORY_INHERIT_ACE, two ACEs are placed on the list will provide a new location or a set of alternate locations directory.
   One for the file system.  The client will use this information to
   redirect its requests directory itself and one which is an inheritable ACE for
   newly created directories.  This flag tells the server to not place
   an ACE on the new server.

6.1.  Replication

   It newly created directory which is expected that file system replication will be used in the case inheritable by
   subdirectories of read-only data.  Typically, the file system will be replicated on
   two or more servers. created directory.

   ACE4_SUCCESSFUL_ACCESS_ACE_FLAG

   ACL4_FAILED_ACCESS_ACE_FLAG

   The fs_locations attribute will provide the
   list of these locations ACE4_SUCCESSFUL_ACCESS_ACE_FLAG (SUCCESS) and
   ACE4_FAILED_ACCESS_ACE_FLAG (FAILED) flag bits relate only to
   ACE4_SYSTEM_AUDIT_ACE_TYPE (AUDIT) and ACE4_SYSTEM_ALARM_ACE_TYPE
   (ALARM) ACE types. If during the client.  On first access of the file
   system, the client should obtain the value processing of the fs_locations
   attribute.  If, in the future, the client finds the server
   unresponsive, file's ACL, the client may attempt to use another
   server specified
   by fs_locations.

   If applicable, the client must take encounters an AUDIT or ALARM ACE that matches the appropriate steps to recover
   valid filehandles from principal
   attempting the new server.  This is described in more
   detail in OPEN, the following sections.

6.2.  Migration

   File system migration is used to move a file system from one server
   to another.  Migration is typically used for a file system notes that is
   writable fact, and has a single copy.  The expected use of migration is for
   load balancing or general resource reallocation.  The protocol does
   not specify how the file system will be moved between servers.  This
   server-to-server transfer mechanism is left to the server
   implementor.  However, the method used to communicate prescence,
   if any, of the migration
   event between client SUCCESS and server is specified here.

   Once the servers participating FAILED flags encountered in the migration have completed the
   move of AUDIT or
   ALARM ACE. Once the file system, server completes the error NFS4ERR_MOVED will be returned for
   subsequent requests received by ACL processing, and the original server.  The
   NFS4ERR_MOVED error is returned for all operations except PUTFH
   share reservation processing, and
   GETATTR.  Upon receiving the NFS4ERR_MOVED error, OPEN call, it then notes if the client will
   obtain
   OPEN succeeded or failed. If the value of OPEN succeeded, and if the fs_locations attribute.  The client will SUCCESS
   flag was set for a matching AUDIT or ALARM, then
   use the contents of appropriate
   AUDIT or ALARM event occurs. If the attribute to redirect its requests to OPEN failed, and if the
   specified server.  To facilitate FAILED
   flag was set for the use of GETATTR, operations such matching AUDIT or ALARM, then the appropriate

Draft Specification      NFS version 4 Protocol                July              August 2002

   as PUTFH must also be accepted by the server for

   AUDIT or ALARM event occurs.  Clearly either or both of the migrated file
   system's filehandles.  Note that SUCCESS
   or FAILED can be set, but if neither is set, the server returns NFS4ERR_MOVED,
   the server MUST support the fs_locations attribute.

   If the client requests more attributes than just fs_locations, the
   server may return fs_locations only.  This AUDIT or ALARM ACE
   is not useful.

   The previously described processing applies to be expected since
   the server has migrated that of the file system and may ACCESS
   operation as well.  The difference being that "success" or "failure"
   does not have mean whether ACCESS returns NFS4_OK or not.  Success means
   whether ACCESS returns all requested and supported bits.  Failure
   means whether ACCESS failed to return a method of
   obtaining additional attribute data.

   The server implementor needs bit that was requested and
   supported.

   ACE4_IDENTIFIER_GROUP

   Indicates that the "who" refers to be careful in developing a migration
   solution. GROUP as defined under UNIX.

   The server must consider all of the state information
   clients may have outstanding at bitmask constants used for the server.  This includes but is not
   limited to locking/share state, delegation state, and asynchronous
   file writes which flag field are represented by WRITE and COMMIT verifiers.  The as follows:

   const ACE4_FILE_INHERIT_ACE             = 0x00000001;
   const ACE4_DIRECTORY_INHERIT_ACE        = 0x00000002;
   const ACE4_NO_PROPAGATE_INHERIT_ACE     = 0x00000004;
   const ACE4_INHERIT_ONLY_ACE             = 0x00000008;
   const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG   = 0x00000010;
   const ACE4_FAILED_ACCESS_ACE_FLAG       = 0x00000020;
   const ACE4_IDENTIFIER_GROUP             = 0x00000040;

   A server should strive to minimize the impact on its clients during and
   after the migration process.

6.3.  Interpretation need not support any of these flags.  If the fs_locations Attribute

   The fs_location attribute is structured in server supports
   flags that are similar to, but not exactly the following way:

   struct fs_location {
           utf8string      server<>;
           pathname4       rootpath;
   };

   struct fs_locations {
           pathname4       fs_root;
           fs_location     locations<>;
   };

   The fs_location struct is used to represent same as, these flags,
   the location of a file
   system by providing implementation may define a server name mapping between the protocol-defined
   flags and the path to implementation-defined flags.  Again, the root of guiding
   principle is that the file system. not appear to be more secure than it
   really is.

   For example, suppose a multi-homed server or a client tries to set of servers that use
   the same rootpath, an array of server names may be provided.  An
   entry in ACE with
   ACE4_FILE_INHERIT_ACE set but not ACE4_DIRECTORY_INHERIT_ACE.  If the
   server array is an UTF8 string and represents one of a
   traditional DNS host name, IPv4 address, or IPv6 address.  It is does not
   a requirement that all servers that share the same rootpath be listed
   in one fs_location struct.  The array support any form of ACL inheritance, the server names is provided for
   convenience.  Servers that share
   should reject the same rootpath may also be listed
   in separate fs_location entries in request with NFS4ERR_ATTRNOTSUPP.  If the fs_locations attribute.

   The fs_locations struct server
   supports a single "inherit ACE" flag that applies to both files and attribute then contains an array of
   locations.  Since
   directories, the name space of each server may be constructed
   differently, reject the "fs_root" field is provided.  The path represented
   by fs_root represents request (i.e., requiring the location of
   client to set both the file system in the server's
   name space.  Therefore, and directory inheritance flags).  The
   server may also accept the fs_root path is only associated with request and silently turn on the
   server from
   ACE4_DIRECTORY_INHERIT_ACE flag.

5.11.4.  ACE who

   There are several special identifiers ("who") which the fs_locations attribute was obtained.  The
   fs_root path is meant need to aid the client be
   understood universally, rather than in locating the file system
   at context of a particular
   DNS domain. Some of these identifiers cannot be understood when an
   NFS client accesses the various servers listed. server, but have meaning when a local process

Draft Specification      NFS version 4 Protocol                July              August 2002

   As an example, there is a replicated file system located at two
   servers (servA and servB).  At servA the file system is located at
   path "/a/b/c".  At servB

   accesses the file system file. The ability to display and modify these
   permissions is located at path "/x/y/z".
   In this example permitted over NFS, even if none of the client accesses access methods
   on the file system first at servA
   with a multi-component lookup path server understands the identifiers.

   Who                    Description
   _______________________________________________________________
   "OWNER"                The owner of "/a/b/c/d".  Since the client
   used file.
   "GROUP"                The group associated with the file.
   "EVERYONE"             The world.
   "INTERACTIVE"          Accessed from an interactive terminal.
   "NETWORK"              Accessed via the network.
   "DIALUP"               Accessed as a multi-component lookup dialup user to obtain the filehandle at "/a/b/c/d",
   it is unaware that the file system's root is located server.
   "BATCH"                Accessed from a batch job.
   "ANONYMOUS"            Accessed without any authentication.
   "AUTHENTICATED"        Any authenticated user (opposite of
                          ANONYMOUS)
   "SERVICE"              Access from a system service.

   To avoid conflict, these special identifiers are distinguish by an
   appended "@" and should appear in servA's the form "xxxx@" (note: no domain
   name
   space at "/a/b/c".  When after the client switches "@").  For example: ANONYMOUS@.

5.11.5.  Mode Attribute

   The NFS version 4 mode attribute is based on the UNIX mode bits. The
   following bits are defined:

        const MODE4_SUID = 0x800;  /* set user id on execution */
        const MODE4_SGID = 0x400;  /* set group id on execution */
        const MODE4_SVTX = 0x200;  /* save text even after use */
        const MODE4_RUSR = 0x100;  /* read permission: owner */
        const MODE4_WUSR = 0x080;  /* write permission: owner */
        const MODE4_XUSR = 0x040;  /* execute permission: owner */
        const MODE4_RGRP = 0x020;  /* read permission: group */
        const MODE4_WGRP = 0x010;  /* write permission: group */
        const MODE4_XGRP = 0x008;  /* execute permission: group */
        const MODE4_ROTH = 0x004;  /* read permission: other */
        const MODE4_WOTH = 0x002;  /* write permission: other */
        const MODE4_XOTH = 0x001;  /* execute permission: other */

   Bits MODE4_RUSR, MODE4_WUSR, and MODE4_XUSR apply to servB, it will need the principal
   identified in the owner attribute.  Bits MODE4_RGRP, MODE4_WGRP, and
   MODE4_XGRP apply to determine that the directory it first referenced at servA is now
   represented by principals identified in the path "/x/y/z/d" on servB.  To facilitate this, owner_group
   attribute.  Bits MODE4_ROTH, MODE4_WOTH, MODE4_XOTH apply to any
   principal that does not match that in the
   fs_locations attribute provided by servA would owner group, and does not
   have a fs_root value group matching that of "/a/b/c" the owner_group attribute.

   The remaining bits are not defined by this protocol and two entries in fs_location.  One entry in fs_location
   will MUST NOT be for itself (servA) and the other will

Draft Specification      NFS version 4 Protocol              August 2002

   used.  The minor version mechanism must be for servB with used to define further bit
   usage.

   Note that in UNIX, if a
   path of "/x/y/z".  With this information, file has the client is able MODE4_SGID bit set and no
   MODE4_XGRP bit set, then READ and WRITE must use mandatory file
   locking.

5.11.6.  Mode and ACL Attribute

   The server that supports both mode and ACL must take care to
   substitute "/x/y/z" for
   synchronize the "/a/b/c" at MODE4_*USR, MODE4_*GRP, and MODE4_*OTH bits with the beginning
   ACEs which have respective who fields of its access
   path "OWNER@", "GROUP@", and construct "/x/y/z/d" to use for
   "EVERYONE@" so that the new server.

6.4.  Filehandle Recovery client can see semantically equivalent access
   permissions exist whether the client asks for Migration owner, owner_group and
   mode attributes, or Replication

   Filehandles for file systems that are replicated or migrated
   generally have just the same semantics as for file systems ACL.

   Because the mode attribute includes bits (e.g. MODE4_SVTX) that are not
   replicated or migrated.  For example, if a file system has persistent
   filehandles and have
   nothing to do with ACL semantics, it is migrated permitted for clients to another server,
   specify both the filehandle
   values ACL attribute and mode in the same SETATTR
   operation. However, because there is no prescribed order for
   processing the file system will be valid at attributes in a SETATTR, the new server.

   For volatile filehandles, client must ensure that
   ACL attribute, if specified without mode, would produce the servers involved likely do not have a
   mechanism to transfer filehandle format desired
   mode bits, and content between
   themselves.  Therefore, a server may have difficulty in determining conversely, the mode attribute if specified without
   ACL, would produce the desired "OWNER@", "GROUP@", and "EVERYONE@"
   ACEs.

5.11.7.  mounted_on_fileid

   UNIX-based operating environments connect a volatile filehandle from an old server should return an error filesystem into the
   namespace by connecting (mounting) the filesystem onto the existing
   file object (the mount point, usually a directory) of
   NFS4ERR_FHEXPIRED.  Therefore, an existing
   filesystem. When the client mount point's parent directory is informed, with read via an
   API like readdir(), the use return results are directory entries, each
   with a component name and a fileid. The fileid of the fh_expire_type attribute, whether volatile filehandles mount point's
   directory entry will
   expire at be different from the migration or replication event.  If fileid that the bit
   FH4_VOL_MIGRATION stat()
   system call returns. The stat() system call is set in returning the fh_expire_type attribute, fileid
   of the client
   must treat root of the volatile filehandle as if mounted filesystem, whereas readdir() is returning
   the server had fileid stat() would have returned before any filesystems were
   mounted on the
   NFS4ERR_FHEXPIRED error.  At mount point.

   Unlike NFS version 3, NFS version 4 allows a client's LOOKUP request
   to cross other filesystems. The client detects the migration or replication event in filesystem
   crossing whenever the presence filehandle argument of LOOKUP has an fsid
   attribute different from that of the FH4_VOL_MIGRATION bit, the filehandle returned by LOOKUP. A
   UNIX-based client will not
   present the original or old volatile file handle consider this a "mount point crossing".  UNIX
   has a legacy scheme for allowing a process to the new server.
   The client will start determine its communication with current
   working directory. This relies on readdir() of a mount point's parent
   and stat() of the new server by
   recovering its filehandles using mount point returning fileids as previously
   described.  The mounted_on_fileid attribute corresponds to the saved file names. fileid
   that readdir() would have returned as described previously.

Draft Specification      NFS version 4 Protocol                July              August 2002

7.

   While the NFS Server Name Space

7.1.  Server Exports

   On version 4 client could simply fabricate a UNIX server fileid
   corresponding to what mounted_on_fileid provides (and if the name space describes all server
   does not support mounted_on_fileid, the files reachable by
   pathnames under client has no choice), there
   is a risk that the root directory or "/".  On client will generate a Windows NT server fileid that conflicts with
   one that is already assigned to another object in the name space constitutes all filesystem.
   Instead, if the files on disks named by mapped
   disk letters.  NFS server administrators rarely make the entire
   server's file system name space available to NFS clients.  More often
   portions of the name space are made available via an "export"
   feature.  In previous versions of can provide the NFS protocol, mounted_on_fileid, the root
   filehandle
   potential for each export client operational problems in this area is obtained through the MOUNT protocol; eliminated.

   If the client sends a string server detects that identifies there is no mounted point at the export of name space
   and target
   file object, then the server value for mounted_on_fileid that it returns is
   the root filehandle for it.  The MOUNT
   protocol supports an EXPORTS procedure same as that will enumerate of the
   server's exports.

7.2.  Browsing Exports fileid attribute.

   The NFS version 4 protocol provides a root filehandle that clients
   can use to obtain filehandles mounted_on_fileid attribute is RECOMMENDED, so the server SHOULD
   provide it if possible, and for these exports via a multi-component
   LOOKUP.  A common user experience UNIX-based server, this is
   straightforward. Usually, mounted_on_fileid will be requested during
   a READDIR operation, in which case it is trivial (at least for UNIX-
   based servers) to use return mounted_on_fileid since it is equal to the
   fileid of a graphical user
   interface (perhaps directory entry returned by readdir().  If
   mounted_on_fileid is requested in a file "Open" dialog window) to find GETATTR operation, the server
   should obey an invariant that has it returning a value that is equal
   to the file via
   progressive browsing through object's entry in the object's parent directory, i.e.
   what readdir() would have returned.  Some operating environments
   allow a directory tree.  The client must series of two or more filesystems to be
   able mounted onto a single
   mount point. In this case, for the server to move from one export obey the aforementioned
   invariant, it will need to another export via single-component,
   progressive LOOKUP operations.

   This style of browsing is find the base mount point, and not well supported by the
   intermediate mount points.

Draft Specification      NFS version 2 4 Protocol              August 2002

6.  Filesystem Migration and
   3 protocols.  The client expects all LOOKUP operations to remain
   within a single Replication

   With the use of the recommended attribute "fs_locations", the NFS
   version 4 server file system. has a method of providing filesystem migration or
   replication services.  For example, the device
   attribute will not change.  This prevents purposes of migration and replication,
   a client from taking name
   space paths filesystem will be defined as all files that span exports.

   An automounter on share a given fsid
   (both major and minor values are the client can obtain same).

   The fs_locations attribute provides a snapshot list of filesystem locations.
   These locations are specified by providing the server's server name space using the EXPORTS procedure of (either
   DNS domain or IP address) and the MOUNT protocol.  If it
   understands path name representing the server's pathname syntax, it can create an image root of
   the server's name space filesystem.  Depending on the client.  The parts type of service being provided, the name space
   that are not exported by the server are filled in with
   list will provide a "pseudo file
   system" that allows new location or a set of alternate locations for
   the user filesystem.  The client will use this information to browse from one mounted file system redirect its
   requests to another.  There the new server.

6.1.  Replication

   It is a drawback to this representation expected that filesystem replication will be used in the case
   of read-only data.  Typically, the
   server's name space filesystem will be replicated on
   two or more servers.  The fs_locations attribute will provide the client: it is static.  If
   list of these locations to the server
   administrator adds a new export client.  On first access of the
   filesystem, the client will be unaware should obtain the value of it.

7.3.  Server Pseudo File System

   NFS version 4 servers avoid this name space inconsistency by
   presenting all the exports within fs_locations
   attribute.  If, in the future, the framework of a single server
   name space.  An NFS version 4 client uses LOOKUP and READDIR
   operations to browse seamlessly from one export to another.  Portions

Draft Specification      NFS version 4 Protocol                July 2002

   of finds the server name space that are not exported are bridged via a
   "pseudo file system" that provides a view of exported directories
   only.  A pseudo file system has a unique fsid and behaves like a
   normal, read only file system.

   Based on
   unresponsive, the construction of client may attempt to use another server specified
   by fs_locations.

   If applicable, the server's name space, it client must take the appropriate steps to recover
   valid filehandles from the new server.  This is possible
   that multiple pseudo file systems may exist.  For example,

   /a         pseudo file system
   /a/b       real file system
   /a/b/c     pseudo file system
   /a/b/c/d   real file system

   Each of described in more
   detail in the pseudo file systems are consider separate entities and
   therefore will have following sections.

6.2.  Migration

   Filesystem migration is used to move a unique fsid.

7.4.  Multiple Roots

   The DOS and Windows operating environments are sometimes described as
   having "multiple roots".  File systems are commonly represented as
   disk letters.  MacOS represents file systems as top level names.  NFS
   version 4 servers filesystem from one server to
   another.  Migration is typically used for these platforms can construct a pseudo file
   system above these root names so filesystem that disk letters or volume names
   are simply directory names in the pseudo root.

7.5.  Filehandle Volatility is
   writable and has a single copy.  The nature expected use of the server's pseudo file system migration is that it for
   load balancing or general resource reallocation.  The protocol does
   not specify how the filesystem will be moved between servers.  This
   server-to-server transfer mechanism is a logical
   representation of file system(s) available from left to the server.
   Therefore, server
   implementor.  However, the pseudo file system is most likely constructed
   dynamically when method used to communicate the migration
   event between client and server is first instantiated.  It is expected
   that specified here.

   Once the pseudo file system may not servers participating in the migration have an on disk counterpart from
   which persistent filehandles could be constructed.  Even though it is
   preferable that completed the server provide persistent filehandles for
   move of the
   pseudo file system, filesystem, the NFS client should expect that pseudo file
   system filehandles are volatile.  This can error NFS4ERR_MOVED will be confirmed returned for
   subsequent requests received by checking the associated "fh_expire_type" attribute original server.  The
   NFS4ERR_MOVED error is returned for those filehandles in
   question.  If all operations except PUTFH and
   GETATTR.  Upon receiving the filehandles are volatile, NFS4ERR_MOVED error, the NFS client must be
   prepared to recover a filehandle will
   obtain the value (e.g. with a multi-component
   LOOKUP) when receiving an error of NFS4ERR_FHEXPIRED.

7.6.  Exported Root

   If the server's root file system is exported, one might conclude that
   a pseudo-file system is not needed.  This would be wrong.  Assume fs_locations attribute.  The client will then
   use the
   following file systems on a server:

           /       disk1  (exported)
           /a      disk2  (not exported) contents of the attribute to redirect its requests to the
   specified server.  To facilitate the use of GETATTR, operations such

Draft Specification      NFS version 4 Protocol                July              August 2002

           /a/b    disk3  (exported)

   Because disk2 is not exported, disk3 cannot be reached with simple
   LOOKUPs.  The server

   as PUTFH must bridge also be accepted by the gap with a pseudo-file system.

7.7.  Mount Point Crossing

   The server for the migrated file system environment may be constructed in such a way
   system's filehandles.  Note that one file system contains a directory which is 'covered' or
   mounted upon by a second file system.  For example:

           /a/b            (file system 1)
           /a/b/c/d        (file system 2)

   The pseudo file system for this server may be constructed to look
   like:

           /               (place holder/not exported)
           /a/b            (file system 1)
           /a/b/c/d        (file system 2)

   It is if the server's responsibility to present server returns NFS4ERR_MOVED,
   the pseudo file system
   that is complete to server MUST support the client. fs_locations attribute.

   If the client sends a lookup request
   for the path "/a/b/c/d", requests more attributes than just fs_locations, the server's response
   server may return fs_locations only.  This is the filehandle of
   the file system "/a/b/c/d".  In previous versions of the NFS
   protocol, to be expected since
   the server would respond with the directory "/a/b/c/d"
   within has migrated the file system "/a/b". filesystem and may not have a method of
   obtaining additional attribute data.

   The NFS client will be able server implementor needs to determine if it crosses be careful in developing a migration
   solution.  The server mount
   point by a change in the value must consider all of the "fsid" attribute.

7.8.  Security Policy and Name Space Presentation

   The application of state information
   clients may have outstanding at the server's security policy needs server.  This includes but is not
   limited to be carefully
   considered locking/share state, delegation state, and asynchronous
   file writes which are represented by the implementor.  One may choose WRITE and COMMIT verifiers.  The
   server should strive to limit the
   viewability of portions of minimize the pseudo file system based impact on its clients during and
   after the
   server's perception migration process.

6.3.  Interpretation of the client's ability fs_locations Attribute

   The fs_location attribute is structured in the following way:

   struct fs_location {
           utf8string      server<>;
           pathname4       rootpath;
   };

   struct fs_locations {
           pathname4       fs_root;
           fs_location     locations<>;
   };

   The fs_location struct is used to authenticate itself
   properly.  However, with represent the support location of multiple security mechanisms a
   filesystem by providing a server name and the ability path to negotiate the appropriate root of the
   filesystem.  For a multi-homed server or a set of servers that use
   the same rootpath, an array of these mechanisms, server names may be provided.  An
   entry in the server array is unable to properly determine if an UTF8 string and represents one of a client will
   traditional DNS host name, IPv4 address, or IPv6 address.  It is not
   a requirement that all servers that share the same rootpath be able
   to authenticate itself.  If, based on its policies, listed
   in one fs_location struct.  The array of server names is provided for
   convenience.  Servers that share the same rootpath may also be listed
   in separate fs_location entries in the fs_locations attribute.

   The fs_locations struct and attribute then contains an array of
   locations.  Since the name space of each server
   chooses to limit may be constructed
   differently, the contents "fs_root" field is provided.  The path represented
   by fs_root represents the location of the pseudo file system, filesystem in the server's
   name space.  Therefore, the fs_root path is only associated with the
   server
   may effectively hide file systems from a which the fs_locations attribute was obtained.  The
   fs_root path is meant to aid the client that may otherwise
   have legitimate access. in locating the filesystem at
   the various servers listed.

Draft Specification      NFS version 4 Protocol                July              August 2002

8.  File Locking

   As an example, there is a replicated filesystem located at two
   servers (servA and Share Reservations

   Integrating locking into the NFS protocol necessarily causes it to be
   state-full.  With the inclusion of "share" file locks servB).  At servA the protocol
   becomes substantially more dependent on state than filesystem is located at
   path "/a/b/c".  At servB the traditional
   combination of NFS and NLM [XNFS].  There are three components to
   making this state manageable:

   o    Clear division between client and server

   o    Ability to reliably detect inconsistency in state between client
        and server

   o    Simple and robust recovery mechanisms filesystem is located at path "/x/y/z".
   In this model, the server owns example the state information.  The client
   communicates its view accesses the filesystem first at servA
   with a multi-component lookup path of this state to "/a/b/c/d".  Since the server as needed.  The client is also able to detect inconsistent state before modifying
   used a
   file.

   To support Win32 "share" locks it is necessary multi-component lookup to atomically OPEN or
   CREATE files.  Having a separate share/unshare operation would not
   allow correct implementation of obtain the Win32 OpenFile API.  In order to
   correctly implement share semantics, filehandle at "/a/b/c/d",
   it is unaware that the previous NFS protocol
   mechanisms used when a file filesystem's root is opened or created (LOOKUP, CREATE,
   ACCESS) located in servA's name
   space at "/a/b/c".  When the client switches to servB, it will need
   to be replaced.  The NFS version 4 protocol has an OPEN
   operation determine that subsumes the NFS version 3 methodology directory it first referenced at servA is now
   represented by the path "/x/y/z/d" on servB.  To facilitate this, the
   fs_locations attribute provided by servA would have a fs_root value
   of LOOKUP,
   CREATE, "/a/b/c" and ACCESS.  However, because many operations require two entries in fs_location.  One entry in fs_location
   will be for itself (servA) and the other will be for servB with a
   filehandle,
   path of "/x/y/z".  With this information, the traditional LOOKUP client is preserved to map a file name able to
   filehandle without establishing state on
   substitute "/x/y/z" for the server.  The policy "/a/b/c" at the beginning of
   granting its access or modifying files is managed by
   path and construct "/x/y/z/d" to use for the server based new server.

   See the section "Security Considerations" for a discussion on the client's state.  These mechanisms can implement policy ranging
   from advisory only locking
   recommendations for the security flavor to full mandatory locking.

8.1.  Locking

   It is assumed be used by any GETATTR
   operation that manipulating a lock is rare when compared to READ
   and WRITE operations.  It is also assumed requests the "fs_locations" attribute.

6.4.  Filehandle Recovery for Migration or Replication

   Filehandles for filesystems that crashes and network
   partitions are relatively rare.  Therefore replicated or migrated generally
   have the same semantics as for filesystems that are not replicated or
   migrated.  For example, if a filesystem has persistent filehandles
   and it is important that migrated to another server, the
   READ and WRITE operations filehandle values for the
   filesystem will be valid at the new server.

   For volatile filehandles, the servers involved likely do not have a lightweight
   mechanism to indicate if
   they possess transfer filehandle format and content between
   themselves.  Therefore, a held lock.  A lock request contains the heavyweight
   information required to establish server may have difficulty in determining
   if a lock and uniquely define the lock
   owner.

   The following sections describe the transition volatile filehandle from an old server should return an error of
   NFS4ERR_FHEXPIRED.  Therefore, the heavy weight
   information to the eventual stateid used for most client and server
   locking and lease interactions.

8.1.1.  Client ID

   For each LOCK request, the client must identify itself to the server.

Draft Specification      NFS version 4 Protocol                July 2002

   This is done in such a way as to allow for correct lock
   identification and crash recovery.  Client identification is
   accomplished with two values.

   o    A verifier that is used to detect client reboots.

   o    A variable length opaque array to uniquely define a client.

        For an operating system this may be a fully qualified host
        name or IP address.  For a user level NFS client it may
        additionally contain a process id or other unique sequence.

   The data structure for the Client ID would then appear as:

           struct nfs_client_id {
                   opaque verifier[4];
                   opaque id<>;
           }

   It is possible through the mis-configuration of a client or the
   existence of a rogue client that two clients end up using the same
   nfs_client_id.  This situation is avoided by "negotiating" the
   nfs_client_id between client and server informed, with the use
   of the
   SETCLIENTID and SETCLIENTID_CONFIRM operations.  The following
   describes fh_expire_type attribute, whether volatile filehandles will
   expire at the two scenarios of negotiation.

   1    Client has never connected to migration or replication event.  If the server

        In this case bit
   FH4_VOL_MIGRATION is set in the client generates an nfs_client_id and
        unless another client has fh_expire_type attribute, the same nfs_client_id.id field, client
   must treat the server accepts volatile filehandle as if the request. The server also records the
        principal (or principal to uid mapping) from the credential
        in the RPC request that contains the nfs_client_id
        negotiation request (SETCLIENTID operation).

        Two clients might still use had returned the same nfs_client_id.id due
        to perhaps configuration
   NFS4ERR_FHEXPIRED error.  For example, a High
        Availability configuration where the nfs_client_id.id is
        derived from the ethernet controller address and both
        systems have the same address.  In this case,  At the result is
        a switched union that returns, migration or replication event in addition to
        NFS4ERR_CLID_INUSE,
   the network address (the rpcbind netid
        and universal address) presence of the FH4_VOL_MIGRATION bit, the client that is using will not
   present the id.

   2    Client is re-connecting original or old volatile filehandle to the server after a client reboot

        In this case, the new server.
   The client still generates an nfs_client_id
        but the nfs_client_id.id field will be the same as the
        nfs_client_id.id generated prior to reboot.  If start its communication with the new server
        finds that the principal/uid is equal to the previously
        "registered" nfs_client_id.id, by
   recovering its filehandles using the server creates and saved file names.

Draft Specification      NFS version 4 Protocol                July              August 2002

        returns

7.  NFS Server Name Space

7.1.  Server Exports

   On a new clientid in response to UNIX server the SETCLIENTID.  If name space describes all the principal/uid is not equal, then this is files reachable by
   pathnames under the root directory or "/".  On a rogue client
        and Windows NT server
   the request is returned in error.  For more discussion
        of crash recovery semantics, see name space constitutes all the section files on "Crash
        Recovery".

   It is possible for a retransmission of request to be received disks named by the
   server after the mapped
   disk letters.  NFS server has acted upon and responded to administrators rarely make the original
   client request.  Therefore entire
   server's filesystem name space available to mitigate effects NFS clients.  More often
   portions of the retransmission name space are made available via an "export"
   feature.  In previous versions of the SETCLIENTID operation, NFS protocol, the root
   filehandle for each export is obtained through the MOUNT protocol;
   the client and server use sends a
   confirmation step.  The client uses the SETCLIENTID_CONFIRM operation
   with the server provided clientid to confirm string that identifies the client's use export of the
   new clientid.  Once name space
   and the server receives the confirmation from the
   client, returns the locking state root filehandle for the client is released.

   In both cases, upon success, NFS4_OK is returned.  To help reduce the
   amount of data transferred on OPEN and LOCK, the server it.  The MOUNT
   protocol supports an EXPORTS procedure that will also
   return enumerate the
   server's exports.

7.2.  Browsing Exports

   The NFS version 4 protocol provides a unique 64-bit clientid value root filehandle that is clients
   can use to obtain filehandles for these exports via a shorthand reference multi-component
   LOOKUP.  A common user experience is to the nfs_client_id values presented by the client.  From this point
   forward, the client will use the clientid to refer a graphical user
   interface (perhaps a file "Open" dialog window) to itself. find a file via
   progressive browsing through a directory tree.  The clientid assigned by the server should client must be chosen so that it will
   able to move from one export to another export via single-component,
   progressive LOOKUP operations.

   This style of browsing is not conflict with a clientid previously assigned well supported by the server.  This
   applies across server restarts or reboots.  When a clientid is
   presented to a server NFS version 2 and that clientid is not recognized, as would
   happen after
   3 protocols.  The client expects all LOOKUP operations to remain
   within a single server reboot, filesystem.  For example, the server device attribute
   will reject the request with
   the error NFS4ERR_STALE_CLIENTID.  When this happens, not change.  This prevents a client from taking name space paths
   that span exports.

   An automounter on the client must can obtain a new clientid by use snapshot of the SETCLIENTID operation and then
   proceed to any other necessary recovery for the server reboot case
   (See the section "Server Failure and Recovery").

   The client must also employ the SETCLIENTID operation when it
   receives a NFS4ERR_STALE_STATEID error server's
   name space using a stateid derived from
   its current clientid, since this also indicates a server reboot which
   has invalidated the existing clientid (see the next section
   "nfs_lockowner and stateid Definition" for details).

8.1.2.  Server Release EXPORTS procedure of Clientid

   If the server determines that MOUNT protocol.  If it
   understands the client holds no associated state
   for its clientid, server's pathname syntax, it can create an image of
   the server may choose to release server's name space on the clientid. client.  The
   server may make this choice for an inactive client so parts of the name space
   that resources are not consumed exported by those intermittently active clients.  If the
   client contacts the server after this release, the server must ensure
   the client receives the appropriate error so that it will use the
   SETCLIENTID/SETCLIENTID_CONFIRM sequence to establish are filled in with a new identity.
   It should be clear "pseudo
   filesystem" that allows the server must be very hesitant user to release browse from one mounted
   filesystem to another.  There is a
   clientid since drawback to this representation of
   the resulting work server's name space on the client: it is static.  If the server
   administrator adds a new export the client to recover from such
   an event will be unaware of it.

7.3.  Server Pseudo Filesystem

   NFS version 4 servers avoid this name space inconsistency by
   presenting all the same burden as if exports within the server had failed and
   restarted.  Typically framework of a single server would not release a clientid unless
   there had been no activity from that
   name space.  An NFS version 4 client for many minutes. uses LOOKUP and READDIR
   operations to browse seamlessly from one export to another.  Portions

Draft Specification      NFS version 4 Protocol                July              August 2002

8.1.3.  nfs_lockowner and stateid Definition

   When requesting a lock, the client must present to the server the
   clientid and an identifier for the owner

   of the requested lock.
   These two fields server name space that are referred to as the nfs_lockowner and the
   definition not exported are bridged via a
   "pseudo filesystem" that provides a view of those fields are:

   o exported directories
   only.  A clientid returned by pseudo filesystem has a unique fsid and behaves like a
   normal, read only filesystem.

   Based on the server as part construction of the client's use server's name space, it is possible
   that multiple pseudo filesystems may exist.  For example,

   /a         pseudo filesystem
   /a/b       real filesystem
   /a/b/c     pseudo filesystem
   /a/b/c/d   real filesystem

   Each of the SETCLIENTID operation.

   o    A variable length opaque array used to uniquely define the owner
        of pseudo filesystems are considered separate entities and
   therefore will have a lock managed by the client.

        This may be unique fsid.

7.4.  Multiple Roots

   The DOS and Windows operating environments are sometimes described as
   having "multiple roots".  filesystems are commonly represented as
   disk letters.  MacOS represents filesystems as top level names.  NFS
   version 4 servers for these platforms can construct a thread id, process id, pseudo file
   system above these root names so that disk letters or other unique value.

   When volume names
   are simply directory names in the server grants pseudo root.

7.5.  Filehandle Volatility

   The nature of the lock, server's pseudo filesystem is that it responds with a unique 64-bit
   stateid.  The stateid is used as a shorthand reference to logical
   representation of filesystem(s) available from the
   nfs_lockowner, since server.
   Therefore, the server will be maintaining pseudo filesystem is most likely constructed
   dynamically when the
   correspondence between them.

   The server is free to form the stateid in any manner first instantiated.  It is expected
   that it chooses
   as long as the pseudo filesystem may not have an on disk counterpart from
   which persistent filehandles could be constructed.  Even though it is able to recognize invalid and out-of-date stateids.
   preferable that the server provide persistent filehandles for the
   pseudo filesystem, the NFS client should expect that pseudo file
   system filehandles are volatile.  This requirement includes those stateids generated can be confirmed by earlier
   instances of checking
   the server.  From this, associated "fh_expire_type" attribute for those filehandles in
   question.  If the filehandles are volatile, the NFS client can must be properly
   notified of
   prepared to recover a server restart.  This notification will occur filehandle value (e.g. with a multi-component
   LOOKUP) when receiving an error of NFS4ERR_FHEXPIRED.

7.6.  Exported Root

   If the
   client presents server's root filesystem is exported, one might conclude that
   a stateid to pseudo-filesystem is not needed.  This would be wrong.  Assume the server from
   following filesystems on a previous
   instantiation. server:

           /       disk1  (exported)
           /a      disk2  (not exported)

Draft Specification      NFS version 4 Protocol              August 2002

           /a/b    disk3  (exported)

   Because disk2 is not exported, disk3 cannot be reached with simple
   LOOKUPs.  The server must be able to distinguish the following situations and
   return bridge the error as specified:

   o    The stateid was generated by an earlier server instance (i.e.
        before gap with a server reboot).  The error NFS4ERR_STALE_STATEID should
        be returned.

   o pseudo-filesystem.

7.7.  Mount Point Crossing

   The stateid was generated by the current server instance but the
        stateid no longer designates the current locking state for the
        lockowner-file pair filesystem environment may be constructed in question (i.e. such a way
   that one filesystem contains a directory which is 'covered' or more locking
        operations has occurred).
   mounted upon by a second filesystem.  For example:

           /a/b            (filesystem 1)
           /a/b/c/d        (filesystem 2)

   The error NFS4ERR_OLD_STATEID should pseudo filesystem for this server may be returned.

        This error condition will only occur when constructed to look
   like:

           /               (place holder/not exported)
           /a/b            (filesystem 1)
           /a/b/c/d        (filesystem 2)

   It is the server's responsibility to present the pseudo filesystem
   that is complete to the client.  If the client issues a
        locking request which changes sends a stateid while an I/O lookup request
        that uses that stateid
   for the path "/a/b/c/d", the server's response is outstanding.

   o    The stateid was generated by the current filehandle of
   the filesystem "/a/b/c/d".  In previous versions of the NFS protocol,
   the server instance but would respond with the
        stateid does not designate a locking state for any active
        lockowner-file pair. filehandle of directory "/a/b/c/d"
   within the filesystem "/a/b".

   The error NFS4ERR_BAD_STATEID should be
        returned.

        This error condition NFS client will occur when there has been be able to determine if it crosses a logic

Draft Specification      NFS version 4 Protocol                July 2002

        error on server mount
   point by a change in the part value of the client or server.  This should not
        happen. "fsid" attribute.

7.8.  Security Policy and Name Space Presentation

   The application of the server's security policy needs to be carefully
   considered by the implementor.  One mechanism that may be used choose to satisfy these requirements is for limit the server to divide stateids into three fields:

   o    A server verifier which uniquely designates a particular server
        instantiation.

   o    An index into a table
   viewability of portions of locking-state structures.

   o    A sequence value which is incremented for each stateid that is
        associated with the same index into pseudo filesystem based on the locking-state table.

   By matching
   server's perception of the incoming stateid and its field values client's ability to authenticate itself
   properly.  However, with the state
   held at support of multiple security mechanisms
   and the server, ability to negotiate the appropriate use of these mechanisms,
   the server is able unable to easily properly determine if a
   stateid is valid for client will be able
   to authenticate itself.  If, based on its current instantiation and state.  If the
   stateid is not valid, policies, the appropriate error can be supplied server
   chooses to limit the
   client.

8.1.4.  Use contents of the stateid

   All READ, WRITE and SETATTR operations contain pseudo filesystem, the server
   may effectively hide filesystems from a stateid.  For client that may otherwise
   have legitimate access.

   As suggested practice, the
   purposes of this section, SETATTR operations which change server should apply the size
   attribute security policy of
   a file are treated as if they are writing the area
   between the old and new size (i.e. shared resource in the range truncated or added server's namespace to the file by means ancestors
   components of the SETATTR), even where SETATTR namespace.  For example:

           /

Draft Specification      NFS version 4 Protocol              August 2002

           /a/b
           /a/b/c
   The /a/b/c directory is not
   explicitly mentioned in the text.

   If the nfs_lockowner performs a READ or WRITE in a situation in which
   it has established a lock on real filesystem and is the server (and shared resource.
   The security policy for these purposes any
   OPEN constitutes a share lock) the stateid (previously returned by /a/b/c is Kerberos with integrity.  The
   server should should apply the server) must be used same security policy to indicate what locks, including both
   record /, /a, and share locks, are held by the lockowner.  If no state is
   established by
   /a/b.  This allows for the client, either record lock or share lock, a
   stateid of all bits 0 is used.  Regardless extension of whether a stateid the protection of
   all bits 0, or a stateid returned by the server is used, if no
   conflicting locks are held on
   server's namespace to the file, ancestors of the server may service real shared resource.

   For the
   READ or WRITE operation.  If a conflict with an explicit lock occurs,
   an error is returned for case of the operation (NFS4ERR_LOCKED). This allows
   "mandatory locking" to be implemented.

   Share locks are established by OPEN operations and by their nature
   are mandatory use of multiple, disjoint security mechanisms in that when
   the OPEN denies READ or WRITE operations,
   that denial results in such operations being rejected with error
   NFS4ERR_LOCKED.  Record locks may be implemented by server's resources, the server as
   either mandatory or advisory, or security for a particular object in the choice of mandatory or advisory
   behavior may
   server's namespace should be determined by the server on the basis union of the file
   being accessed.  When record locks are advisory, they only prevent
   the granting all security mechanisms of conflicting lock requests and have no effect on
   all direct descendants.

Draft Specification      NFS version 4 Protocol                July              August 2002

   READ's or WRITE's.  Mandatory record locks, however, prevent
   conflicting IO operations

8.  File Locking and when they are attempted, they are
   rejected with NFS4ERR_LOCKED.

   Every stateid other than Share Reservations

   Integrating locking into the special stateid values noted above,
   whether returned by an OPEN-type operation (i.e. OPEN,
   OPEN_DOWNGRADE), or by a LOCK-type operation (i.e. LOCK or LOCKU),
   defines an access mode for NFS protocol necessarily causes it to be
   stateful.  With the file (i.e. READ, WRITE, or READ_WRITE)
   as established by inclusion of share reservations the original OPEN which began protocol
   becomes substantially more dependent on state than the stateid sequence, traditional
   combination of NFS and as modified by subsequent OPEN's NLM [XNFS].  There are three components to
   making this state manageable:

   o    Clear division between client and OPEN_DOWNGRADE's within that
   stateid sequence.  When a READ, WRITE, or SETATTR which specifies server

   o    Ability to reliably detect inconsistency in state between client
        and server

   o    Simple and robust recovery mechanisms

   In this model, the
   size attribute, is done, server owns the operation is subject state information.  The client
   communicates its view of this state to checking against the access mode server as needed.  The
   client is also able to verify that the operation detect inconsistent state before modifying a
   file.

   To support Win32 share reservations it is appropriate given the necessary to atomically
   OPEN with which the or CREATE files.  Having a separate share/unshare operation is associated.

   In the case
   would not allow correct implementation of WRITE-type operations (i.e. WRITE's and SETATTR's
   which set size), the server must verify that the access mode allows
   writing and return an NFS4ERR_OPENMODE error if it does not. Win32 OpenFile API.  In
   order to correctly implement share semantics, the
   case, of READ, the server may perform the corresponding check on the
   access mode, previous NFS
   protocol mechanisms used when a file is opened or it may choose to allow READ on opens for WRITE only,
   to accommodate clients whose write implementation may unavoidably do
   reads (e.g. due created (LOOKUP,
   CREATE, ACCESS) need to buffer cache constraints).  However, even if
   READ's are allowed in these circumstances, the server MUST still
   check for locks be replaced.  The NFS version 4 protocol has
   an OPEN operation that conflict with subsumes the READ (e.g. another open
   specify denial NFS version 3 methodology of READ's).  Note that
   LOOKUP, CREATE, and ACCESS.  However, because many operations require
   a server which does enforce filehandle, the
   access mode check traditional LOOKUP is preserved to map a file name
   to filehandle without establishing state on READ's need not explicitly check for conflicting
   share reservations since the existence server.  The policy
   of OPEN for read granting access
   guarantees that no conflicting share reservation or modifying files is managed by the server based
   on the client's state.  These mechanisms can exist.

   A stateid of all bits 1 (one) allows READ operations to bypass implement policy ranging
   from advisory only locking checks at the server.  However, WRITE operations with to full mandatory locking.

8.1.  Locking

   It is assumed that manipulating a
   stateid with bits all 1 (one) do not bypass locking checks lock is rare when compared to READ
   and WRITE operations.  It is also assumed that crashes and network
   partitions are
   treated exactly relatively rare.  Therefore it is important that the same as
   READ and WRITE operations have a lightweight mechanism to indicate if
   they possess a stateid of all bits 0 were used.

   An explicit held lock.  A lock may not be granted while a READ or WRITE operation
   with conflicting implicit locking is being performed.  For request contains the
   purposes of this paragraph, heavyweight
   information required to establish a READ is considered as having an
   implicit shared record lock for and uniquely define the area being read while a WRITE is
   considered as having an implicit exclusive record lock for
   owner.

   The following sections describe the area
   being written (and similarly transition from the heavy weight
   information to the eventual stateid used for SETATTR's that set size as discussed
   above).

8.1.5.  Sequencing of Lock Requests

   Locking is different than most NFS operations as it requires "at-
   most-one" semantics that are not provided by ONCRPC.  ONCRPC over a
   reliable transport is not sufficient because a sequence of client and server
   locking
   requests may span multiple TCP connections.  In the face of
   retransmission or reordering, lock or unlock requests must have a
   well defined and consistent behavior.  To accomplish this, lease interactions.

8.1.1.  Client ID

   For each lock
   request contains a sequence number that is a consecutively increasing LOCK request, the client must identify itself to the server.

Draft Specification      NFS version 4 Protocol                July              August 2002

   integer.  Different nfs_lockowners have different sequences.  The
   server maintains the last sequence number (L) received and the
   response that was returned.

   Note that for requests that contain

   This is done in such a sequence number, way as to allow for each
   nfs_lockowner, there should be no more than one outstanding request.

   If correct lock
   identification and crash recovery.  A sequence of a request (r) with SETCLIENTID
   operation followed by a previous sequence number (r < L) is received,
   it SETCLIENTID_CONFIRM operation is rejected with required to
   establish the return identification onto the server.  Establishment of error NFS4ERR_BAD_SEQID.  Given
   identification by a
   properly-functioning client, new incarnation of the response to (r) must have been
   received before client also has the last request (L) was sent.  If a duplicate effect
   of
   last request (r == L) is received, the stored response is returned.
   If immediately breaking any leased state that a request beyond the next sequence (r == L + 2) is received, it is
   rejected with the return previous incarnation
   of error NFS4ERR_BAD_SEQID.  Sequence
   history is reinitialized whenever the client verifier changes.

   Since might have had on the sequence number is represented with an unsigned 32-bit
   integer, server, as opposed to forcing the arithmetic involved with
   new client incarnation to wait for the sequence number is mod
   2^32.

   It is critical leases to expire.  Breaking
   the lease state amounts to the server maintain removing all lock, share
   reservation, and, where the last response sent to server is not supporting the
   CLAIM_DELEGATE_PREV claim type, all delegation state associated with
   same client to provide a more reliable cache of duplicate non-idempotent
   requests than that with the same identity. For discussion of delegation
   state recovery, see the traditional cache described section "Delegation Recovery".

   Client identification is encapsulated in [Juszczak]. the following structure:

           struct nfs_client_id4 {
                   verifier4     verifier;
                   opaque        id<NFS4_OPAQUE_LIMIT>;
           };

   The traditional duplicate request cache uses first field, verifier is a least recently client incarnation verifier that is
   used
   algorithm for removing unneeded requests. However, to detect client reboots. Only if the last lock
   request and response on a given nfs_lockowner must be cached as long
   as verifier is different from
   that the lock state exists on server has previously recorded the server.

8.1.6.  Recovery from Replayed Requests

   As described above, client (as identified by
   the sequence number is per nfs_lockowner.  As
   long as second field f the server maintains structure, id) does the last sequence number received and
   follows server start the methods described above, there are no risks
   process of a
   Byzantine router re-sending old requests. cancelling the client's leased state.

   The server need only
   maintain second field, id is a variable length string that uniquely
   defines the (nfs_lockowner, sequence number) state as long as there client.

   There are open files or closed files with locks outstanding.

   LOCK, LOCKU, OPEN, OPEN_DOWNGRADE, and CLOSE each contain a sequence
   number and therefore several considerations for how the risk of client generates the replay of these operations
   resulting in undesired effects is non-existent while id
   string:

   o    The string should be unique so that multiple clients do not
        present the server
   maintains same string. The consequences of two clients
        presenting the nfs_lockowner state.

8.1.7.  Releasing nfs_lockowner State

   When a particular nfs_lockowner no longer holds open or file locking same string range from one client getting an
        error to one client having its leased state at abruptly and
        unexpectedly cancelled.

   o    The string should be selected so the server, subsequent incarnations
        (e.g. reboots) of the server may choose to release same client cause the sequence
   number state associated with client to present
        the nfs_lockowner. same string. The server may make implementor is cautioned from an approach
        that requires the string to be recorded in a local file because
        this choice based on lease expiration, for precludes the reclamation use of server
   memory, or other implementation specific details.  In any event, the
   server implementation in an environment
        where there is able to do this safely only when the nfs_lockowner no

Draft Specification local disk and all file access is from an NFS
        version 4 Protocol                July 2002

   longer is being utilized by the client. server.

   o    The string should be different for each server may choose to
   hold the nfs_lockowner state in the event network address
        that retransmitted requests
   are received.  However, the period client accesses, rather than common to hold this state all server
        network addresses. The reason is
   implementation specific.

   In the case that a LOCK, LOCKU, OPEN_DOWNGRADE, or CLOSE is
   retransmitted after it may not be possible for
        the client to tell if same server has previously released is listening on multiple
        network addresses. If the
   nfs_lockowner state, client issues SETCLIENTID with the

Draft Specification      NFS version 4 Protocol              August 2002

        same id string to each network address of such a server, the
        server will find that think it is the nfs_lockowner has
   no files open same client, and an error each successive
        SETCLIENTID will be returned cause the server to begin the client.  If process of
        removing the
   nfs_lockowner does have a file open, client's previous leased state.

   o    The algorithm for generating the stateid will string should not match assume that
        the client's network address won't change.  This includes
        changes between client incarnations and
   again an error even changes while the
        client is returned to stilling running in its current incarnation. This
        means that if the client.

   In client includes just the case that an OPEN is retransmitted client's and server's
        network address in the nfs_lockowner id string, there is
   being used for the first time or the nfs_lockowner state has been
   previously released by a real risk, after
        the server, client gives up the use of network address, that another client,
        using a similar algorithm for generate the OPEN_CONFIRM
   operation id string, will prevent incorrect behavior.  When the server observes
        generating a conflicting id string.

   Given the use above considerations, an example of the nfs_lockowner for the first time, a well generated id
   string is one that includes:

   o    The server's network address.

   o    The client's network address.

   o    For a user level NFS version 4 client, it will direct should contain
        additional information to distinguish the client from other user
        level clients running on the same host, such as a process id or
        other unique sequence.

   o    Additional information that tends to be unique, such as one or
        more of:

        - The client machines serial number (for privacy reasons, it is
          best to perform some one way function on the OPEN_CONFIRM for the corresponding OPEN.  This
   sequence establishes the use of an nfs_lockowner and associated
   sequence number.  See the section "OPEN_CONFIRM serial number).

        - A MAC address.

        - Confirm Open" for
   further details.

8.2.  Lock Ranges The protocol allows a lock owner to request a lock with a byte range
   and then either upgrade or unlock a sub-range timestamp of when the initial lock.
   It NFS version 4 software was first
          installed on the client (though this is expected subject to the
          previously mentioned caution about using information that this will be an uncommon type of request.  In any
   case, servers or server is
          stored in a file, because the file systems may not might only be able accessible
          over NFS version 4).

        - A true random number. However since this number ought to support sub-
   range lock semantics.  In be
          the event same between client incarnations, this shares the same
          problem as that of the using the timestamp of the software
          installation.

   As a security measure, the server receives a locking
   request that represents MUST NOT cancel a sub-range of current locking client's leased
   state for if the
   lock owner, principal established the server state for a given id string is allowed to return the error
   NFS4ERR_LOCK_RANGE to signify that it does
   not support sub-range lock
   operations.  Therefore, the client should be prepared to receive this
   error and, if appropriate, report same as the error to principal issuing the requesting
   application.

   The client is discouraged from combining multiple independent locking
   ranges SETCLIENTID.

   Note that happen to be adjacent into SETCLIENTID and SETCLIENTID_CONFIRM has a single request since secondary purpose

Draft Specification      NFS version 4 Protocol              August 2002

   of establishing the information the server may not support sub-range requests and needs to make callbacks to
   the client for reasons related purpose of supporting delegations. It is permitted to
   change this information via SETCLIENTID and SETCLIENTID_CONFIRM
   within the recovery same incarnation of file locking state in the event client without removing the
   client's leased state.

   Once a SETCLIENTID and SETCLIENTID_CONFIRM sequence has successfully
   completed, the client uses the short hand client identifier, of type
   clientid4, instead of server failure.
   As discussed in the section "Server Failure longer and Recovery" below, less compact nfs_client_id4
   structure.  This short hand client identfier (a clientid) is assigned
   by the server may employ certain optimizations during recovery and should be chosen so that work
   effectively only when it will not conflict with
   a clientid previously assigned by the client's behavior during lock recovery server.  This applies across
   server restarts or reboots.  When a clientid is
   similar presented to a server
   and that clientid is not recognized, as would happen after a server
   reboot, the client's locking behavior prior to server failure.

8.3.  Blocking Locks

   Some clients require will reject the support of blocking locks.  The NFS version
   4 protocol request with the error
   NFS4ERR_STALE_CLIENTID.  When this happens, the client must not rely on obtain a callback mechanism
   new clientid by use of the SETCLIENTID operation and therefore is
   unable then proceed to notify a
   any other necessary recovery for the server reboot case (See the
   section "Server Failure and Recovery").

   The client must also employ the SETCLIENTID operation when it
   receives a previously denied lock NFS4ERR_STALE_STATEID error using a stateid derived from
   its current clientid, since this also indicates a server reboot which
   has been

Draft Specification      NFS version 4 Protocol                July 2002

   granted.  Clients have no choice but to continually poll for invalidated the
   lock.  This presents a fairness problem.  Two new lock types are
   added, READW existing clientid (see the next section
   "lock_owner and WRITEW, stateid Definition" for details).

   See the detailed descriptions of SETCLIENTID and are used to indicate to SETCLIENTID_CONFIRM
   for a complete specification of the operations.

8.1.2.  Server Release of Clientid

   If the server determines that the client is requesting a blocking lock.  The server should maintain
   an ordered list of pending blocking locks.  When the conflicting lock
   is released, holds no associated state
   for its clientid, the server may wait choose to release the lease period clientid.  The
   server may make this choice for an inactive client so that resources
   are not consumed by those intermittently active clients.  If the first
   waiting
   client to re-request contacts the lock.  After server after this release, the lease period
   expires server must ensure
   the next waiting client request is allowed receives the lock.  Clients
   are required to poll at an interval sufficiently small appropriate error so that it is
   likely to acquire will use the lock in
   SETCLIENTID/SETCLIENTID_CONFIRM sequence to establish a timely manner.  The new identity.
   It should be clear that the server is not
   required must be very hesitant to maintain release a list of pending blocked locks as it is used to
   increase fairness and not correct operation.  Because of
   clientid since the
   unordered nature of crash recovery, storing of lock state resulting work on the client to stable
   storage would recover from such
   an event will be required to guarantee ordered granting of blocking
   locks.

   Servers may also note the lock types same burden as if the server had failed and delay returning denial of
   restarted.  Typically a server would not release a clientid unless
   there had been no activity from that client for many minutes.

   Note that if the id string in a SETCLIENTID request is properly
   constructed, and if the client takes care to allow extra time use the same principal
   for a conflicting lock to each successive use of SETCLIENTID, then, barring an active
   denial of service attack, NFS4ERR_CLID_INUSE should never be
   released, allowing
   returned.

   However, client bugs, server bugs, or perhaps a successful return.  In this way, clients can
   avoid the burden deliberate change of needlessly frequent polling for blocking locks.
   The server should take care in

Draft Specification      NFS version 4 Protocol              August 2002

   the length principal owner of delay in the event the
   client retransmits id string (such as the request.

8.4.  Lease Renewal

   The purpose case of a lease client
   that changes security flavors, and under the new flavor, there is no
   mapping to allow a server to remove stale locks the previous owner) will in rare cases result in
   NFS4ERR_CLID_INUSE.

   In that are held by event, when the server gets a SETCLIENTID for a client id
   that currently has crashed no state, or is otherwise
   unreachable.  It is not a mechanism for cache consistency and lease
   renewals may not be denied if it has state, but the lease interval has not expired.

   The following events cause implicit renewal of all of
   expired, rather than returning NFS4ERR_CLID_INUSE, the leases for
   a given client (i.e. all those sharing a given clientid).  Each of
   these is server MUST
   allow the SETCLIENTID, and confirm the new clientid if followed by
   the appropriate SETCLIENTID_CONFIRM.

8.1.3.  lock_owner and stateid Definition

   When requesting a positive indication that lock, the client is still active and
   that must present to the associated state held at server the server,
   clientid and an identifier for the client, is
   still valid.

   o    An OPEN with a valid clientid.

   o    Any operation made with a valid stateid (CLOSE, DELEGPURGE,
        DELEGRETURN, LOCK, LOCKU, OPEN, OPEN_CONFIRM, OPEN_DOWNGRADE,
        READ, RENEW, SETATTR, SETCLIENTID_CONFIRM, WRITE).  This does
        not include the special stateids owner of all bits 0 or all bits 1.

        Note that if the client had restarted or rebooted, requested lock.
   These two fields are referred to as the
        client would not be making these requests without issuing lock_owner and the SETCLIENTID/SETCLIENTID_CONFIRM sequence.  The use definition
   of
        the SETCLIENTID/SETCLIENTID_CONFIRM operations notifies those fields are:

   o    A clientid returned by the server as part of the client's use of
        the SETCLIENTID operation.

   o    A variable length opaque array used to drop uniquely define the locking state associated with owner
        of a lock managed by the client.

        If

        This may be a thread id, process id, or other unique value.

   When the server has rebooted, grants the stateids

Draft Specification      NFS version 4 Protocol                July 2002

        (NFS4ERR_STALE_STATEID error) or lock, it responds with a unique stateid.
   The stateid is used as a shorthand reference to the clientid
        (NFS4ERR_STALE_CLIENTID error) lock_owner, since
   the server will not be valid hence
        preventing spurious renewals.

   This approach allows for low overhead lease renewal which scales
   well.  In maintaining the typical case no extra RPC calls are required for lease
   renewal and in correspondence between them.

   The server is free to form the worst case one RPC stateid in any manner that it chooses
   as long as it is required every lease period
   (i.e. a RENEW operation).  The number of locks held able to recognize invalid and out-of-date stateids.
   This requirement includes those stateids generated by earlier
   instances of the client is
   not a factor since all state for server.  From this, the client is involved with the
   lease renewal action.

   Since all operations that create can be properly
   notified of a new lease also renew existing
   leases, the server must maintain a common lease expiration time for
   all valid leases for a given client. restart.  This lease time can then be
   easily updated upon implicit lease renewal actions.

8.5.  Crash Recovery

   The important requirement in crash recovery is that both notification will occur when the
   client
   and presents a stateid to the server know when the other has failed.  Additionally, it is
   required that a client sees from a consistent view of data across previous
   instantiation.

   The server
   restarts or reboots.  All READ and WRITE operations that may have
   been queued within the client or network buffers must wait until the
   client has successfully recovered the locks protecting be able to distinguish the READ and
   WRITE operations.

8.5.1.  Client Failure following situations and Recovery

   In
   return the event that error as specified:

   o    The stateid was generated by an earlier server instance (i.e.
        before a client fails, server reboot).  The error NFS4ERR_STALE_STATEID should
        be returned.

   o    The stateid was generated by the current server may recover instance but the client's
   locks when
        stateid no longer designates the associated leases have expired.  Conflicting locks
   from another client may only be granted after this lease expiration.
   If current locking state for the client is able to restart
        lockowner-file pair in question (i.e. one or reinitialize within the lease
   period the client may more locking
        operations has occurred).  The error NFS4ERR_OLD_STATEID should
        be forced to wait the remainder of the lease
   period before obtaining new locks.

   To minimize client delay upon restart, lock requests are associated
   with an instance of returned.

Draft Specification      NFS version 4 Protocol              August 2002

        This error condition will only occur when the client by issues a client supplied verifier.  This
   verifier
        locking request which changes a stateid while an I/O request
        that uses that stateid is part of the initial SETCLIENTID call made outstanding.

   o    The stateid was generated by the client.
   The current server returns a clientid as a result of instance but the SETCLIENTID
   operation.
        stateid does not designate a locking state for any active
        lockowner-file pair.  The client then confirms error NFS4ERR_BAD_STATEID should be
        returned.

        This error condition will occur when there has been a logic
        error on the use part of the clientid with
   SETCLIENTID_CONFIRM.  The clientid in combination with an opaque
   owner field is then used by the client to identify the lock owner for
   OPEN. or server.  This chain of associations is then should not
        happen.

   One mechanism that may be used to identify all locks satisfy these requirements is for a particular client.

   Since
   the verifier will be changed by server to,

   o    divide the client upon "other" field of each
   initialization, the stateid into two fields:

        - A server can compare a new verifier to the verifier
   associated with currently held locks and determine that they do not
   match.  This signifies the client's new instantiation and subsequent
   loss of locking state.  As which uniquely designates a result, the particular
        server
          instantiation.

        - An index into a table of locking-state structures.

   o    utilize the "seqid" field of each stateid, such that seqid is
        monotonically incremented for each stateid that is free to release

Draft Specification      NFS version 4 Protocol                July 2002

   all locks held which are associated
        with the old clientid which was
   derived from the old verifier.

   For secure environments, a change in same index into the verifier must only cause locking-state table.

   By matching the
   release of locks associated incoming stateid and its field values with the authenticated requester.  This state
   held at the server, the server is required able to prevent easily determine if a rogue entity from freeing otherwise
   stateid is valid
   locks.

   Note that for its current instantiation and state.  If the verifier must have
   stateid is not valid, the same uniqueness properties of appropriate error can be supplied to the verifier for
   client.

8.1.4.  Use of the COMMIT operation.

8.5.2.  Server Failure stateid and Recovery

   If Locking

   All READ, WRITE and SETATTR operations contain a stateid.  For the server loses locking state (usually as
   purposes of this section, SETATTR operations which change the size
   attribute of a result file are treated as if they are writing the area
   between the old and new size (i.e. the range truncated or added to
   the file by means of the SETATTR), even where SETATTR is not
   explicitly mentioned in the text.

   If the lock_owner performs a restart READ or reboot), WRITE in a situation in which it must allow clients time to discover this fact and re-
   establish
   has established a lock or share reservation on the lost locking state.  The client server (any OPEN
   constitutes a share reservation) the stateid (previously returned by
   the server) must be able used to re-
   establish indicate what locks, including both
   record locks and share reservations, are held by the locking lockowner.  If
   no state without having is established by the server deny valid
   requests because client, either record lock or share
   reservation, a stateid of all bits 0 is used.  Regardless whether a
   stateid of all bits 0, or a stateid returned by the server has granted conflicting access to another
   client.  Likewise, is used,

Draft Specification      NFS version 4 Protocol              August 2002

   if there is the possibility that clients have not
   yet re-established their locking state for a conflicting share reservation or mandatory record lock
   held on the file, the server must
   disallow MUST refuse to service the READ and or WRITE
   operation.

   Share reservations are established by OPEN operations for and by their
   nature are mandatory in that file.  The duration of
   this recovery period is equal to the duration of when the lease period.

   A client can determine OPEN denies READ or WRITE
   operations, that server failure (and thus loss of locking
   state) has occurred, when it receives one of two errors.  The
   NFS4ERR_STALE_STATEID denial results in such operations being rejected
   with error indicates a stateid invalidated NFS4ERR_LOCKED.  Record locks may be implemented by a
   reboot the
   server as either mandatory or restart.  The NFS4ERR_STALE_CLIENTID error indicates a
   clientid invalidated by reboot advisory, or restart.  When either the choice of these are
   received, mandatory or
   advisory behavior may be determined by the client must establish a new clientid (See server on the section
   "Client ID") and re-establish the locking state as discussed below.

   The period of special handling basis of locking and READs and WRITEs, equal
   in duration to the lease period, is referred to as
   file being accessed (for example, some UNIX-based servers support a
   "mandatory lock bit" on the "grace
   period".  During mode attribute such that if set, record
   locks are required on the grace period, clients recover file before I/O is possible).  When record
   locks and are advisory, they only prevent the
   associated state by reclaim-type locking requests (i.e. LOCK requests
   with reclaim set to true and OPEN operations with a claim type granting of
   CLAIM_PREVIOUS).  During the grace period, the server must reject
   READ and WRITE operations and non-reclaim locking conflicting
   lock requests (i.e.
   other LOCK and OPEN operations) have no effect on READ's or WRITE's.  Mandatory
   record locks, however, prevent conflicting I/O operations.  When they
   are attempted, they are rejected with NFS4ERR_LOCKED. Assuming an error of NFS4ERR_GRACE.

   If the server can reliably determine
   operating environment like UNIX that granting requires it, when the client
   gets NFS4ERR_LOCKED on a non-reclaim
   request file it knows it has the proper share
   reservation for, it will not conflict with reclamation need to issue a LOCK request on the region
   of locks by other clients, the NFS4ERR_GRACE error does not have to be returned and file that includes the non-
   reclaim client request can be serviced.  For region the server I/O was to be able performed on,
   with an appropriate locktype (i.e. READ*_LT for a READ operation,
   WRITE*_LT for a WRITE operation).

   With NFS version 3, there was no notion of a stateid so there was no
   way to
   service tell if the application process of the client sending the READ and
   or WRITE operations during operation had also acquired the grace period, it must
   again be able appropriate record lock on
   the file. Thus there was no way to guarantee implement mandatory locking. With
   the stateid construct, this barrier has been removed.

   Note that no possible conflict could arise for UNIX environments that support mandatory file locking,
   the distinction between an impending reclaim advisory and mandatory locking request is subtle.  In
   fact, advisory and mandatory record locks are exactly the READ or WRITE
   operation. same in so
   far as the APIs and requirements on implementation. If the server mandatory
   lock attribute is unable set on the file, the server checks to offer that guarantee, see if the
   NFS4ERR_GRACE error must
   lockowner has an appropriate shared (read) or exclusive (write)
   record lock on the region it wishes to read or write to. If there is
   no appropriate lock, the server checks if there is a conflicting lock
   (which can be returned done by attempting to acquire the client. conflicting lock on
   the behalf of the lockowner, and if successful, release the lock
   after the READ or WRITE is done), and if there is, the server returns
   NFS4ERR_LOCKED.

   For a Windows environments, there are no advisory record locks, so the
   server to provide simple, valid handling always checks for record locks during I/O requests.

   Thus, the grace

Draft Specification NFS version 4 Protocol                July 2002

   period, the easiest method is LOCK operation does not need to simply reject all non-reclaim
   locking requests distinguish
   between advisory and mandatory record locks. It is the NFS version 4
   server's processing of the READ and WRITE operations by returning that introduces
   the
   NFS4ERR_GRACE error.  However, a server may keep information about
   granted locks distinction.

   Every stateid other than the special stateid values noted in stable storage.  With this information, the server
   could determine if a regular lock or READ or WRITE

Draft Specification      NFS version 4 Protocol              August 2002

   section, whether returned by an OPEN-type operation can be
   safely processed.

   For example, if a count of locks on (i.e. OPEN,
   OPEN_DOWNGRADE), or by a given file is available in
   stable storage, the server can track reclaimed locks LOCK-type operation (i.e. LOCK or LOCKU),
   defines an access mode for the file and
   when all reclaims have been processed, non-reclaim locking requests
   may be processed.  This way (i.e. READ, WRITE, or READ-WRITE)
   as established by the server can ensure that non-reclaim
   locking requests will not conflict with potential reclaim requests.
   With respect to I/O requests, if original OPEN which began the server is able to determine stateid sequence,
   and as modified by subsequent OPEN's and OPEN_DOWNGRADE's within that
   there are no outstanding reclaim requests for
   stateid sequence.  When a file by information
   from stable storage READ, WRITE, or another similar mechanism, SETATTR which specifies the processing of
   I/O requests could proceed normally for
   size attribute, is done, the file.

   To reiterate, for a server that allows non-reclaim lock and I/O
   requests operation is subject to be processed during checking against
   the grace period, it MUST determine
   that no lock subsequently reclaimed will be rejected and access mode to verify that no lock
   subsequently reclaimed would have prevented any I/O the operation
   processed during is appropriate given the grace period.

   Clients should be prepared for
   OPEN with which the return of NFS4ERR_GRACE errors for
   non-reclaim lock and I/O requests. operation is associated.

   In this case the client should
   employ a retry mechanism for case of WRITE-type operations (i.e. WRITE's and SETATTR's
   which set size), the request.  A delay (on server must verify that the order of
   several seconds) between retries should be used to avoid overwhelming access mode allows
   writing and return an NFS4ERR_OPENMODE error if it does not.  In the server.  Further discussion
   case, of the general is included in
   [Floyd].  The client must account for READ, the server that is able to may perform I/O and non-reclaim locking requests within the grace period
   as well as those that can not do so.

   A reclaim-type locking request outside corresponding check on the server's grace period can
   only succeed
   access mode, or it may choose to allow READ on opens for WRITE only,
   to accommodate clients whose write implementation may unavoidably do
   reads (e.g. due to buffer cache constraints).  However, even if
   READ's are allowed in these circumstances, the server can guarantee MUST still
   check for locks that no conflicting lock or
   I/O request has been granted since reboot or restart.

8.5.3.  Network Partitions and Recovery

   If conflict with the duration READ (e.g. another open
   specify denial of READ's).  Note that a network partition is greater than the lease
   period provided by the server, the server will have not received a
   lease renewal from which does enforce the client.  If this occurs,
   access mode check on READ's need not explicitly check for conflicting
   share reservations since the server may free
   all locks held existence of OPEN for read access
   guarantees that no conflicting share reservation can exist.

   A stateid of all bits 1 (one) MAY allow READ operations to bypass
   locking checks at the client.  As server.  However, WRITE operations with a result,
   stateid with bits all stateids held by 1 (one) MUST NOT bypass locking checks and are
   treated exactly the
   client will become invalid same as if a stateid of all bits 0 were used.

   A lock may not be granted while a READ or stale.  Once WRITE operation using one
   of the client special stateids is able to
   reach being performed and the server after such a network partition, all I/O submitted by range of the client lock
   request conflicts with the now invalid stateids will fail with range of the server
   returning READ or WRITE operation.  For
   the error NFS4ERR_EXPIRED.  Once purposes of this error paragraph, a conflict occurs when a shared lock
   is received,
   the client will suitably notify the application that held the lock.

   As requested and a courtesy to the client WRITE operation is being performed, or as an optimization, the server may
   continue
   exclusive lock is requested and either a READ or a WRITE operation is
   being performed. A SETATTR that sets size is treated similarly to hold locks on behalf a
   WRITE as discussed above.

8.1.5.  Sequencing of Lock Requests

   Locking is different than most NFS operations as it requires "at-
   most-one" semantics that are not provided by ONCRPC.  ONCRPC over a client for which recent
   communication has extended beyond the lease period.  If
   reliable transport is not sufficient because a sequence of locking
   requests may span multiple TCP connections.  In the face of
   retransmission or reordering, lock or unlock requests must have a
   well defined and consistent behavior.  To accomplish this, each lock
   request contains a sequence number that is a consecutively increasing
   integer.  Different lock_owners have different sequences.  The server
   maintains the last sequence number (L) received and the response that
   was returned.  The first request issued for any given lock_owner is
   issued with a sequence number of zero.

Draft Specification      NFS version 4 Protocol                July              August 2002

   receives

   Note that for requests that contain a sequence number, for each
   lock_owner, there should be no more than one outstanding request.

   If a lock or I/O request that conflicts (r) with one a previous sequence number (r < L) is received,
   it is rejected with the return of these
   courtesy locks, error NFS4ERR_BAD_SEQID.  Given a
   properly-functioning client, the server response to (r) must free the courtesy lock and grant have been
   received before the
   new request. last request (L) was sent.  If a duplicate of
   last request (r == L) is received, the server continues to hold locks stored response is returned.
   If a request beyond the expiration of a
   client's lease, next sequence (r == L + 2) is received, it is
   rejected with the server MUST employ a method return of recording this
   fact in its stable storage.  Conflicting locks requests from another error NFS4ERR_BAD_SEQID.  Sequence
   history is reinitialized whenever the SETCLIENTID/SETCLIENTID_CONFIRM
   sequence changes the client may be serviced after verifier.

   Since the lease expiration.  There are various
   scenarios involving server failure after such sequence number is represented with an event that require unsigned 32-bit
   integer, the storage of these lease expirations or network partitions.  One
   scenario arithmetic involved with the sequence number is as follows:

        A client holds a lock at mod
   2^32.

   It is critical the server and encounters a
        network partition and is unable maintain the last response sent to renew the associated
        lease.  A second
   client obtains to provide a conflicting lock and then
        frees the lock.  After the unlock more reliable cache of duplicate non-idempotent
   requests than that of the traditional cache described in [Juszczak].
   The traditional duplicate request by cache uses a least recently used
   algorithm for removing unneeded requests. However, the second
        client, last lock
   request and response on a given lock_owner must be cached as long as
   the server reboots or reinitializes.  Once lock state exists on the
        server recovers, server.

   The client MUST monotonically increment the network partition heals sequence number for the
   CLOSE, LOCK, LOCKU, OPEN, OPEN_CONFIRM, and OPEN_DOWNGRADE
   operations.  This is true even in the
        original client attempts to reclaim event that the original lock.

   In previous
   operation that used the sequence number received an error.  The only
   exception to this scenario and without any state information, rule is if the server will
   allow previous operation received one of
   the reclaim and following errors: NFS4ERR_STALE_CLIENTID, NFS4ERR_STALE_STATEID,
   NFS4ERR_BAD_STATEID, NFS4ERR_BAD_SEQID.

8.1.6.  Recovery from Replayed Requests

   As described above, the client will be in an inconsistent state
   because sequence number is per lock_owner.  As long
   as the server or maintains the client has last sequence number received and follows
   the methods described above, there are no knowledge risks of the conflicting
   lock. a Byzantine router
   re-sending old requests.  The server may choose to store this lease expiration or network
   partitioning state in a way that will need only identify maintain the client
   (lock_owner, sequence number) state as long as there are open files
   or closed files with locks outstanding.

   LOCK, LOCKU, OPEN, OPEN_DOWNGRADE, and CLOSE each contain a
   whole.  Note that this may potentially lead to lock reclaims being
   denied unnecessarily because sequence
   number and therefore the risk of a mix the replay of conflicting and non-
   conflicting locks.  The these operations
   resulting in undesired effects is non-existent while the server
   maintains the lock_owner state.

8.1.7.  Releasing lock_owner State

   When a particular lock_owner no longer holds open or file locking

Draft Specification      NFS version 4 Protocol              August 2002

   state at the server, the server may also choose to store information
   about each lock that has an expired lease with an release the sequence
   number state associated
   conflicting lock. with the lock_owner.  The server may make
   this choice of based on lease expiration, for the amount and type reclamation of state
   information that is stored is left to the implementor. server
   memory, or other implementation specific details.  In any case, event, the
   server must have enough state information is able to enable correct
   recovery from multiple partitions and multiple server failures.

8.6.  Recovery from a Lock Request Timeout or Abort

   In do this safely only when the event a lock request times out, a client may decide to not
   retry lock_owner no longer
   is being utilized by the request. client.  The client server may also abort the request when choose to hold the
   process for which it was issued is terminated (e.g.
   lock_owner state in UNIX due the event that retransmitted requests are
   received.  However, the period to a
   signal).  It hold this state is possible though implementation
   specific.

   In the case that a LOCK, LOCKU, OPEN_DOWNGRADE, or CLOSE is
   retransmitted after the server received the request
   and acted upon it.  This would change has previously released the state on lock_owner
   state, the server without will find that the client being aware of lock_owner has no files open and
   an error will be returned to the change.  It is paramount that client.  If the
   client re-synchronize state with server before it attempts any other
   operation that takes a seqid and/or lock_owner does have
   a stateid with file open, the same
   nfs_lockowner. This stateid will not match and again an error is straightforward
   returned to do without a special re-
   synchronize operation.

   Since the server maintains client.

8.1.8.  Use of Open Confirmation

   In the last lock request case that an OPEN is retransmitted and response

Draft Specification      NFS version 4 Protocol                July 2002

   received on the nfs_lockowner, lock_owner is being
   used for each nfs_lockowner, the client
   should cache first time or the last lock request it sent such that lock_owner state has been previously
   released by the lock request
   did not receive a response.  From this, server, the next time use of the client does
   a lock OPEN_CONFIRM operation for will
   prevent incorrect behavior.  When the nfs_lockowner, it can send server observes the cached
   request, if there is one, and if use of the request was one that established
   state (e.g. a LOCK or OPEN operation)
   lock_owner for the first time, it will direct the client can follow up with a
   request to remove the state (e.g. a LOCKU or CLOSE operation).  With
   this approach, the sequencing and stateid information on perform
   the client
   and server OPEN_CONFIRM for the given nfs_lockowner will re-synchronize and in
   turn corresponding OPEN.  This sequence
   establishes the lock state will re-synchronize.

8.7.  Server Revocation use of Locks

   At any point, an lock_owner and associated sequence number.
   Since the server can revoke locks held by OPEN_CONFIRM sequence connects a client and new open_owner on the
   client must be prepared for this event.  When
   server with an existing open_owner on a client, the client detects that
   its locks have been or sequence number
   may have been revoked, any value.  The OPEN_CONFIRM step assures the client is
   responsible for validating server that
   the state information between itself and value received is the server.  Validating locking state for correct one.  See the client means that it
   must verify or reclaim state section "OPEN_CONFIRM
   - Confirm Open" for each lock currently held.

   The first instance further details.

   There are a number of lock revocation is upon server reboot or re-
   initialization.  In this instance situations in which the client will receive requirement to confirm
   an error
   (NFS4ERR_STALE_STATEID or NFS4ERR_STALE_CLIENTID) and OPEN would pose difficulties for the client will
   proceed with normal crash recovery as described and server, in that
   they would be prevented from acting in a timely fashion on
   information received, because that information would be provisional,
   subject to deletion upon non-confirmation.  Fortunately, these are
   situations in which the previous
   section.

   The second lock revocation event is server can avoid the inability need for confirmation
   when responding to renew the lease
   period.  While this is considered open requests.  The two constraints are:

   o    The server must not bestow a rare delegation for any open which would
        require confirmation.

   o    The server MUST NOT require confirmation on a reclaim-type open
        (i.e. one specifying claim type CLAIM_PREVIOUS or unusual event,
        CLAIM_DELEGATE_PREV).

        These constraints are related in that reclaim-type opens are the client
   must be prepared to recover.  Both
        only ones in which the server and client will may be able
   to detect the failure required to renew send a
        delegation.  For CLAIM_NULL, sending the lease and delegation is optional
        while for CLAIM_DELEGATE_CUR, no delegation is sent.

Draft Specification      NFS version 4 Protocol              August 2002

        Delegations being sent with an open requiring confirmation are capable of
        troublesome because recovering without data corruption.  For the server, it tracks from non-confirmation adds undue
        complexity to the
   last renewal event serviced for the client and knows when protocol while requiring confirmation on
        reclaim-type opens poses difficulties in that the lease
   will expire.  Similarly, inability to
        resolve the client must track operations which will
   renew status of the reclaim until lease period.  Using expiration may
        make it difficult to have timely determination of the time that each such request was
   sent and set of
        locks being reclaimed (since the time that grace period may expire).

        Requiring open confirmation on reclaim-type opens is avoidable
        because of the corresponding reply was received, nature of the
   client environments in which such opens
        are done.  For CLAIM_PREVIOUS opens, this is immediately after
        server reboot, so there should bound the be no time for lockowners to be
        created, found to be unused, and recycled.  For
        CLAIM_DELEGATE_PREV opens, we are dealing with a client reboot
        situation.  A server which supports delegation can be sure that the corresponding renewal could
        no lockowners for that client have occurred on the server been recycled since client
        initialization and thus determine if it is possible can ensure that
   a lease period expiration could have occurred. confirmation will not be
        required.

8.2.  Lock Ranges

   The third protocol allows a lock revocation event can occur as owner to request a result lock with a byte range
   and then either upgrade or unlock a sub-range of
   administrative intervention within the lease period.  While this is
   considered a rare event, it initial lock.
   It is possible expected that the server's
   administrator has decided to release this will be an uncommon type of request.  In any
   case, servers or revoke a particular server filesystems may not be able to support sub-
   range lock held
   by semantics.  In the client.  As event that a result server receives a locking
   request that represents a sub-range of revocation, current locking state for the
   lock owner, the server is allowed to return the error
   NFS4ERR_LOCK_RANGE to signify that it does not support sub-range lock
   operations.  Therefore, the client will should be prepared to receive an this
   error of NFS4ERR_EXPIRED and and, if appropriate, report the error to the requesting
   application.

   The client is received within discouraged from combining multiple independent locking
   ranges that happen to be adjacent into a single request since the lease
   period
   server may not support sub-range requests and for reasons related to
   the lock.  In this instance recovery of file locking state in the client event of server failure.
   As discussed in the section "Server Failure and Recovery" below, the
   server may assume employ certain optimizations during recovery that work
   effectively only when the nfs_lockowner's locks have been lost.  The client notifies
   the client's behavior during lock holder appropriately.  The client may not assume recovery is
   similar to the lease
   period client's locking behavior prior to server failure.

8.3.  Upgrading and Downgrading Locks

   If a client has been renewed as a result write lock on a record, it can request an atomic
   downgrade of failed operation.

   When the lock to a read lock via the LOCK request, by setting
   the type to READ_LT. If the server supports atomic downgrade, the
   request will succeed. If not, it will return NFS4ERR_LOCK_NOTSUPP.
   The client determines should be prepared to receive this error, and if
   appropriate, report the lease period may have expired, error to the requesting application.

Draft Specification      NFS version 4 Protocol                July              August 2002

   client must mark all locks held for the associated lease as
   "unvalidated".  This means the

   If a client has been unable to re-establish
   or confirm the appropriate a read lock state with the server.  As described
   in the previous section on crash recovery, there are scenarios in
   which the server may grant conflicting locks after the lease period
   has expired for a client.  When record, it is possible that the lease period
   has expired, can request an atomic
   upgrade of the client must validate each lock currently held to
   ensure that a conflicting write lock has not been granted. The client may
   accomplish this task via the LOCK request by issuing an I/O request, either a pending I/O
   or a zero-length read, specifying setting
   the stateid associated with type to WRITE_LT or WRITEW_LT.  If the
   lock in question. server does not support
   atomic upgrade, it will return NFS4ERR_LOCK_NOTSUPP.  If the response to upgrade
   can be achieved without an existing conflict, the request will
   succeed.  Otherwise, the server will return either NFS4ERR_DENIED or
   NFS4ERR_DEADLOCK.  The error NFS4ERR_DEADLOCK is success, returned if the
   client has validated all of the locks governed by that stateid and
   re-established the appropriate state between itself and the server.
   If issued the I/O LOCK request is not successful, then one or more of the locks
   associated with the stateid was revoked by type set to WRITEW_LT and the
   server has detected a deadlock. The client should be prepared to
   receive such errors and if appropriate, report the client
   must notify error to the owner.

8.8.  Share Reservations

   A share reservation is
   requesting application.

8.4.  Blocking Locks

   Some clients require the support of blocking locks.  The NFS version
   4 protocol must not rely on a callback mechanism to control access to a file.  It
   is a separate and independent mechanism from record locking.  When therefore is
   unable to notify a client opens when a file, it issues an OPEN operation previously denied lock has been
   granted.  Clients have no choice but to continually poll for the server
   specifying the type of access required (READ, WRITE, or BOTH)
   lock.  This presents a fairness problem.  Two new lock types are
   added, READW and the
   type of access WRITEW, and are used to indicate to deny others (deny NONE, READ, WRITE, or BOTH).  If the OPEN fails server that
   the client will fail the application's open request.

   Pseudo-code definition is requesting a blocking lock.  The server should maintain
   an ordered list of pending blocking locks.  When the semantics:

                if ((request.access & file_state.deny)) ||
                      (request.deny & file_state.access))
                              return (NFS4ERR_DENIED)

   The constants used for conflicting lock
   is released, the OPEN and OPEN_DOWNGRADE operations server may wait the lease period for the
   access and deny fields are as follows:

   const OPEN4_SHARE_ACCESS_READ   = 0x00000001;
   const OPEN4_SHARE_ACCESS_WRITE  = 0x00000002;
   const OPEN4_SHARE_ACCESS_BOTH   = 0x00000003;

   const OPEN4_SHARE_DENY_NONE     = 0x00000000;
   const OPEN4_SHARE_DENY_READ     = 0x00000001;
   const OPEN4_SHARE_DENY_WRITE    = 0x00000002;
   const OPEN4_SHARE_DENY_BOTH     = 0x00000003;

8.9.  OPEN/CLOSE Operations

   To provide correct share semantics, a first
   waiting client MUST use the OPEN
   operation to obtain re-request the initial filehandle and indicate lock.  After the desired
   access and what if any access to deny.  Even if lease period
   expires the next waiting client intends request is allowed the lock.  Clients
   are required to

Draft Specification      NFS version 4 Protocol                July 2002

   use a stateid of all 0's or all 1's, poll at an interval sufficiently small that it must still obtain the
   filehandle for the regular file with the OPEN operation so is
   likely to acquire the
   appropriate share semantics can be applied.  For clients that do not
   have lock in a deny mode built into their open programming interfaces, deny
   equal to NONE should be used. timely manner.  The OPEN operation with the CREATE flag, also subsumes the CREATE
   operation for regular files server is not
   required to maintain a list of pending blocked locks as it is used in previous versions to
   increase fairness and not correct operation.  Because of the NFS
   protocol.  This allows a create with a share
   unordered nature of crash recovery, storing of lock state to stable
   storage would be done atomically.

   The CLOSE operation removes all share locks held by the nfs_lockowner
   on that file.  If record locks are held, the client SHOULD release
   all locks before issuing a CLOSE.  The server MAY free all
   outstanding locks on CLOSE but some servers required to guarantee ordered granting of blocking
   locks.

   Servers may not support also note the CLOSE lock types and delay returning denial of a file that still has record locks held.  The server MUST return
   failure if any locks would exist after
   the CLOSE.

   The LOOKUP operation will return request to allow extra time for a filehandle without establishing
   any conflicting lock state on the server.  Without to be
   released, allowing a valid stateid, successful return.  In this way, clients can
   avoid the burden of needlessly frequent polling for blocking locks.
   The server
   will assume should take care in the length of delay in the event the
   client has retransmits the least access.  For example, a file
   opened with deny READ/WRITE cannot be accessed using request.

8.5.  Lease Renewal

   The purpose of a filehandle
   obtained through LOOKUP because it would not have lease is to allow a valid stateid
   (i.e. using server to remove stale locks
   that are held by a stateid of all bits 0 client that has crashed or all bits 1).

8.10.  Open Upgrade and Downgrade

   When an OPEN is done for otherwise
   unreachable.  It is not a file and the lockowner mechanism for which cache consistency and lease
   renewals may not be denied if the open
   is being done already lease interval has not expired.

   The following events cause implicit renewal of all of the file open, the result is to upgrade the
   open file status maintained on the server to include the access and
   deny bits specified by the new OPEN as well as those leases for the existing
   OPEN.  The result
   a given client (i.e. all those sharing a given clientid).  Each of
   these is a positive indication that there is one open file, as far as the
   protocol client is concerned, still active and it includes

Draft Specification      NFS version 4 Protocol              August 2002

   that the union of associated state held at the access and
   deny bits server, for all of the client, is
   still valid.

   o    An OPEN requests completed.  Only with a single
   CLOSE will be done to reset valid clientid.

   o    Any operation made with a valid stateid (CLOSE, DELEGPURGE,
        DELEGRETURN, LOCK, LOCKU, OPEN, OPEN_CONFIRM, OPEN_DOWNGRADE,
        READ, RENEW, SETATTR, WRITE).  This does not include the effects special
        stateids of both OPEN's. all bits 0 or all bits 1.

        Note that if the client, when issuing client had restarted or rebooted, the OPEN, may
        client would not know that be making these requests without issuing
        the same file is
   in fact being opened. SETCLIENTID/SETCLIENTID_CONFIRM sequence.  The above only applies if both OPEN's result
   in use of
        the OPEN'ed object being designated by SETCLIENTID/SETCLIENTID_CONFIRM sequence (one that
        changes the same filehandle.

   When client verifier) notifies the server chooses to export multiple filehandles corresponding to drop
        the same file object and returns different filehandles on two
   different OPEN's of locking state associated with the same file object, client.
        SETCLIENTID/SETCLIENTID_CONFIRM never renews a lease.

        If the server MUST NOT "OR"
   together has rebooted, the access and deny bits stateids
        (NFS4ERR_STALE_STATEID error) or the clientid
        (NFS4ERR_STALE_CLIENTID error) will not be valid hence
        preventing spurious renewals.

   This approach allows for low overhead lease renewal which scales
   well.  In the typical case no extra RPC calls are required for lease
   renewal and coalesce in the two open files.
   Instead worst case one RPC is required every lease period
   (i.e. a RENEW operation).  The number of locks held by the client is
   not a factor since all state for the client is involved with the
   lease renewal action.

   Since all operations that create a new lease also renew existing
   leases, the server must maintain separate OPEN's with separate
   stateid's and will require separate CLOSE's to free them.

   When multiple open files on a common lease expiration time for
   all valid leases for a given client.  This lease time can then be
   easily updated upon implicit lease renewal actions.

8.6.  Crash Recovery

   The important requirement in crash recovery is that both the client are merged into a single open
   file object on
   and the server, server know when the close of one other has failed.  Additionally, it is
   required that a client sees a consistent view of data across server
   restarts or reboots.  All READ and WRITE operations that may have
   been queued within the open files (on client or network buffers must wait until the
   client) may necessitate change of
   client has successfully recovered the access and deny status of locks protecting the
   open file on READ and
   WRITE operations.

8.6.1.  Client Failure and Recovery

   In the server.  This is because event that a client fails, the union of server may recover the access and
   deny bits for client's
   locks when the remaining open's associated leases have expired.  Conflicting locks
   from another client may only be smaller (i.e. a proper
   subset) than previously.  The OPEN_DOWNGRADE operation is used to granted after this lease expiration.

Draft Specification      NFS version 4 Protocol                July              August 2002

   make

   If the necessary change and client is able to restart or reinitialize within the lease
   period the client should use it may be forced to update wait the
   server so that share reservation remainder of the lease
   period before obtaining new locks.

   To minimize client delay upon restart, lock requests by other clients are
   handled properly.

8.11.  Short and Long Leases

   When determining associated
   with an instance of the time period for client by a client supplied verifier.  This
   verifier is part of the server lease, initial SETCLIENTID call made by the usual
   lease tradeoffs apply.  Short leases are good for fast client.
   The server
   recovery at returns a cost of increased RENEW or READ (with zero length)
   requests.  Longer leases are certainly kinder and gentler to large
   internet servers trying to handle very large numbers clientid as a result of clients. the SETCLIENTID
   operation.  The
   number client then confirms the use of RENEW requests drop the clientid with
   SETCLIENTID_CONFIRM.  The clientid in proportion combination with an opaque
   owner field is then used by the client to identify the lease time.  The
   disadvantages of long leases are slower recovery after server failure
   (server must wait lock owner for leases to expire and grace period before
   granting new lock requests) and increased file contention (if client
   fails to transmit an unlock request
   OPEN.  This chain of associations is then server must wait used to identify all locks
   for lease
   expiration before granting new locks).

   Long leases are usable if a particular client.

   Since the server is able to store lease state in
   non-volatile memory.  Upon recovery, verifier will be changed by the client upon each
   initialization, the server can reconstruct compare a new verifier to the
   lease state from its non-volatile memory and continue operation verifier
   associated with
   its clients and therefore long leases are not an issue.

8.12.  Clocks currently held locks and Calculating Lease Expiration

   To avoid the need for synchronized clocks, lease times are granted by
   the server as a time delta.  However, there is a requirement determine that the
   client and server clocks they do not drift excessively over
   match.  This signifies the duration client's new instantiation and subsequent
   loss of locking state.  As a result, the lock.  There server is also the issue of propagation delay across free to release
   all locks held which are associated with the
   network old clientid which could easily be several hundred milliseconds as well as was
   derived from the possibility old verifier.

   Note that requests will be lost and need to be
   retransmitted.

   To take propagation delay into account, the client should subtract it
   from lease times (e.g. if verifier must have the client estimates same uniqueness properties of
   the one-way
   propagation delay as 200 msec, then it can assume that verifier for the lease is
   already 200 msec old when it gets it).  In addition, it will take
   another 200 msec to get COMMIT operation.

8.6.2.  Server Failure and Recovery

   If the server loses locking state (usually as a response back result of a restart
   or reboot), it must allow clients time to discover this fact and re-
   establish the server.  So the lost locking state.  The client must send a lock renewal or write data back be able to re-
   establish the locking state without having the server 400 msec
   before deny valid
   requests because the lease would expire.

8.13.  Migration, Replication and State

   When responsibility for handling a given file system is transferred server has granted conflicting access to another
   client.  Likewise, if there is the possibility that clients have not
   yet re-established their locking state for a new server (migration) or file, the client chooses to use an alternate server (e.g. in response must
   disallow READ and WRITE operations for that file.  The duration of
   this recovery period is equal to server unresponsiveness) in the context duration of file system replication, the appropriate handling lease period.

   A client can determine that server failure (and thus loss of state shared
   between locking
   state) has occurred, when it receives one of two errors.  The
   NFS4ERR_STALE_STATEID error indicates a stateid invalidated by a
   reboot or restart.  The NFS4ERR_STALE_CLIENTID error indicates a
   clientid invalidated by reboot or restart.  When either of these are
   received, the client must establish a new clientid (See the section
   "Client ID") and server (i.e. locks, leases, stateid's, and

Draft Specification      NFS version 4 Protocol                July 2002

   clientid's) is re-establish the locking state as described discussed below.

   The period of special handling differs between
   migration and replication.  For related discussion of file server
   state locking and recover of such see the sections under "File Locking and
   Share Reservations"

8.13.1.  Migration READs and State

   In the case of migration, the servers involved WRITEs, equal
   in the migration of a
   file system SHOULD transfer all server state from the original duration to the
   new server.  This must be done in a way that lease period, is transparent referred to as the
   client.  This state transfer will ease the client's transition when a
   file system migration occurs.  If "grace
   period".  During the servers are successful in
   transferring all state, grace period, clients recover locks and the client will continue to use stateid's
   assigned
   associated state by the original server.  Therefore the new server must
   recognize these stateid's as valid.  This holds reclaim-type locking requests (i.e. LOCK requests
   with reclaim set to true for the clientid
   as well.  Since responsibility for an entire file system is
   transferred and OPEN operations with a migration event, there is no possibility that
   conflicts will arise on the new server as a result claim type of
   CLAIM_PREVIOUS).  During the transfer of
   locks.

   As part of grace period, the transfer server must reject

Draft Specification      NFS version 4 Protocol              August 2002

   READ and WRITE operations and non-reclaim locking requests (i.e.
   other LOCK and OPEN operations) with an error of information between servers, leases would
   be transferred as well.  The leases being transferred to NFS4ERR_GRACE.

   If the new server will typically have a different expiration time from those for
   the same client, previously on the new server.  To maintain the
   property can reliably determine that all leases on a given server for granting a given client expire
   at the same time, the server should advance the expiration time to
   the later non-reclaim
   request will not conflict with reclamation of locks by other clients,
   the leases being transferred or the leases already
   present.  This allows the client to maintain lease renewal of both
   classes without special effort.

   The servers may choose NFS4ERR_GRACE error does not have to transfer the state information upon
   migration.  However, this choice is discouraged.  In this case, when be returned and the non-
   reclaim client presents state information from the original server, request can be serviced.  For the
   client must server to be prepared able to receive either NFS4ERR_STALE_CLIENTID or
   NFS4ERR_STALE_STATEID from
   service READ and WRITE operations during the new server.  The client should then
   recover its state information as grace period, it normally would in response to a
   server failure.  The new server must take care
   again be able to allow for the
   recovery of state information as it would in the event of server
   restart.

8.13.2.  Replication guarantee that no possible conflict could arise
   between an impending reclaim locking request and State

   Since client switch-over in the case of replication is not under
   server control, READ or WRITE
   operation.  If the handling of state is different.  In this case,
   leases, stateid's and clientid's do not have validity across a
   transition from one server is unable to another.  The client must re-establish
   its locks on offer that guarantee, the new server.  This can
   NFS4ERR_GRACE error must be compared returned to the re-
   establishment of locks by means of reclaim-type requests after client.

   For a server reboot.  The difference is that to provide simple, valid handling during the server has no provision grace
   period, the easiest method is to
   distinguish simply reject all non-reclaim
   locking requests reclaiming locks from those obtaining new locks

Draft Specification      NFS version 4 Protocol                July 2002

   or to defer and READ and WRITE operations by returning the latter.  Thus, a client re-establishing
   NFS4ERR_GRACE error.  However, a lock on server may keep information about
   granted locks in stable storage.  With this information, the
   new server (by means of
   could determine if a LOCK regular lock or OPEN request), may have the
   requests denied due to READ or WRITE operation can be
   safely processed.

   For example, if a conflicting lock.  Since replication is
   intended for read-only use of filesystems, such denial count of locks
   should not pose large difficulties in practice.  When an attempt to
   re-establish a lock on a new server given file is denied, available in
   stable storage, the client should
   treat server can track reclaimed locks for the situation as if his original lock had file and
   when all reclaims have been revoked.

8.13.3.  Notification of Migrated Lease

   In the case of lease renewal, the client processed, non-reclaim locking requests
   may not be submitting processed.  This way the server can ensure that non-reclaim
   locking requests will not conflict with potential reclaim requests.
   With respect to I/O requests, if the server is able to determine that
   there are no outstanding reclaim requests for a file system that has been migrated to by information
   from stable storage or another server.
   This can occur because similar mechanism, the processing of
   I/O requests could proceed normally for the implicit lease renewal mechanism.  The
   client renews leases file.

   To reiterate, for all file systems when submitting a request server that allows non-reclaim lock and I/O
   requests to be processed during the grace period, it MUST determine
   that no lock subsequently reclaimed will be rejected and that no lock
   subsequently reclaimed would have prevented any one file system at I/O operation
   processed during the server.

   In order grace period.

   Clients should be prepared for the return of NFS4ERR_GRACE errors for
   non-reclaim lock and I/O requests.  In this case the client to schedule renewal should
   employ a retry mechanism for the request.  A delay (on the order of leases that may have
   been relocated
   several seconds) between retries should be used to avoid overwhelming
   the new server, server.  Further discussion of the general issue is included in
   [Floyd].  The client must find out about
   lease relocation before those leases expire.  To accomplish this, all
   operations which implicitly renew leases account for a client (i.e. OPEN,
   CLOSE, READ, WRITE, RENEW, LOCK, LOCKT, LOCKU), will return the error
   NFS4ERR_LEASE_MOVED server that is able to
   perform I/O and non-reclaim locking requests within the grace period
   as well as those that can not do so.

   A reclaim-type locking request outside the server's grace period can
   only succeed if responsibility for any of the leases to be
   renewed server can guarantee that no conflicting lock or
   I/O request has been transferred to granted since reboot or restart.

   A server may, upon restart, establish a new server.  This condition will
   continue until value for the client receives an NFS4ERR_MOVED error and lease
   period.  Therefore, clients should, once a new clientid is

Draft Specification      NFS version 4 Protocol              August 2002

   established, refetch the
   server receives lease_time attribute and use it as the subsequent GETATTR(fs_locations) basis
   for an access to
   each file system lease renewal for which a the lease has been moved to a new associated with that server.

   When However,
   the server must establish, for this restart event, a client receives an NFS4ERR_LEASE_MOVED error, it should
   perform some operation, such grace period at
   least as long as the lease period for the previous server
   instantiation. This allows the client state obtained during the
   previous server instance to be reliably re-established.

8.6.3.  Network Partitions and Recovery

   If the duration of a RENEW, on each file system
   associated network partition is greater than the lease
   period provided by the server, the server will have not received a
   lease renewal from the client.  If this occurs, the server may free
   all locks held for the client.  As a result, all stateids held by the
   client will become invalid or stale.  Once the client is able to
   reach the server after such a network partition, all I/O submitted by
   the client with the now invalid stateids will fail with the server in question.  When
   returning the error NFS4ERR_EXPIRED.  Once this error is received,
   the client receives an
   NFS4ERR_MOVED error, will suitably notify the application that held the lock.

   As a courtesy to the client can follow or as an optimization, the normal process server may
   continue to
   obtain hold locks on behalf of a client for which recent
   communication has extended beyond the lease period.  If the new server information (through
   receives a lock or I/O request that conflicts with one of these
   courtesy locks, the fs_locations
   attribute) server must free the courtesy lock and perform renewal of those leases on grant the
   new server. request.

   If the server has not had state transferred continues to it transparently, it will
   receive either NFS4ERR_STALE_CLIENTID or NFS4ERR_STALE_STATEID hold locks beyond the expiration of a
   client's lease, the server MUST employ a method of recording this
   fact in its stable storage.  Conflicting lock requests from another
   client may be serviced after the new server, lease expiration.  There are various
   scenarios involving server failure after such an event that require
   the storage of these lease expirations or network partitions.  One
   scenario is as described above, follows:

        A client holds a lock at the server and encounters a
        network partition and is unable to renew the associated
        lease.  A second client obtains a conflicting lock and can then recover
        frees the lock.  After the unlock request by the second
        client, the server reboots or reinitializes.  Once the
        server recovers, the network partition heals and the
        original client attempts to reclaim the original lock.

   In this scenario and without any state
   information as it does information, the server will
   allow the reclaim and the client will be in an inconsistent state
   because the event server or the client has no knowledge of the conflicting
   lock.

   The server failure. may choose to store this lease expiration or network
   partitioning state in a way that will only identify the client as a
   whole.  Note that this may potentially lead to lock reclaims being

Draft Specification      NFS version 4 Protocol                July              August 2002

9.  Client-Side Caching

   Client-side caching

   denied unnecessarily because of data, a mix of file attributes, conflicting and of file names is
   essential non-
   conflicting locks.  The server may also choose to providing good performance store information
   about each lock that has an expired lease with an associated
   conflicting lock.  The choice of the NFS protocol.
   Providing distributed cache coherence is a difficult problem amount and
   previous versions type of state
   information that is stored is left to the NFS protocol have not attempted it.
   Instead, several NFS client implementation techniques implementor.  In any case,
   the server must have been used enough state information to reduce enable correct
   recovery from multiple partitions and multiple server failures.

   For further discussion of revocation of locks see the problems that a lack section "Server
   Revocation of coherence poses for users.
   These techniques have not been clearly defined by earlier protocol
   specifications and it is often unclear what is valid Locks".

8.7.  Recovery from a Lock Request Timeout or invalid Abort

   In the event a lock request times out, a client behavior.

   The NFS version 4 protocol uses many techniques similar may decide to those that
   have been used in previous protocol versions.  The NFS version 4
   protocol does not provide distributed cache coherence.  However, it
   defines a more limited set of caching guarantees to allow locks and
   share reservations to be used without destructive interference from
   retry the request.  The client side caching.

   In addition, may also abort the NFS version 4 protocol introduces a delegation
   mechanism request when the
   process for which allows many decisions normally made by it was issued is terminated (e.g. in UNIX due to a
   signal).  It is possible though that the server to
   be made locally by clients. received the request
   and acted upon it.  This mechanism provides efficient
   support would change the state on the server without
   the client being aware of the common cases where sharing is infrequent or where
   sharing change.  It is read-only.

9.1.  Performance Challenges for Client-Side Caching

   Caching techniques used in previous versions of paramount that the NFS protocol have
   been successful in providing good performance.  However, several
   scalability challenges can arise when those techniques are used
   client re-synchronize state with
   very large numbers of clients. server before it attempts any other
   operation that takes a seqid and/or a stateid with the same
   lock_owner. This is particularly true when
   clients are geographically distributed which classically increases straightforward to do without a special re-
   synchronize operation.

   Since the latency server maintains the last lock request and response
   received on the lock_owner, for cache revalidation requests.

   The previous versions of each lock_owner, the NFS protocol repeat their file data client should
   cache validation requests at the last lock request it sent such that the lock request did
   not receive a response.  From this, the next time the file is opened.  This
   behavior client does a
   lock operation for the lock_owner, it can have serious performance drawbacks.  A common case send the cached request, if
   there is one, and if the request was one in which a file is only accessed by that established state (e.g.
   a single client.  Therefore,
   sharing is infrequent.

   In this case, repeated reference to LOCK or OPEN operation), the server to find that no
   conflicts exist is expensive.  A better option with regards to
   performance is to allow a will return the cached result
   or if never saw the request, perform it.  The client that repeatedly opens can follow up
   with a file to do
   so without reference request to remove the server.  This is done until potentially
   conflicting operations from another client actually occur.

   A similar situation arises in connection with file locking.  Sending
   file lock state (e.g. a LOCKU or CLOSE operation).
   With this approach, the sequencing and unlock requests to stateid information on the
   client and server as well as for the read given lock_owner will re-synchronize and
   write requests necessary to make data caching consistent with in
   turn the
   locking semantics (see lock state will re-synchronize.

8.8.  Server Revocation of Locks

   At any point, the section "Data Caching and File Locking") server can severely limit performance. revoke locks held by a client and the
   client must be prepared for this event.  When the client detects that
   its locks have been or may have been revoked, the client is
   responsible for validating the state information between itself and
   the server.  Validating locking state for the client means that it
   must verify or reclaim state for each lock currently held.

   The first instance of lock revocation is used to provide upon server reboot or re-
   initialization.  In this instance the client will receive an error
   (NFS4ERR_STALE_STATEID or NFS4ERR_STALE_CLIENTID) and the client will
   proceed with normal crash recovery as described in the previous

Draft Specification      NFS version 4 Protocol                July              August 2002

   protection against infrequent conflicts, a large penalty

   section.

   The second lock revocation event is incurred.
   This penalty may discourage the use of file locking by applications.

   The NFS version 4 protocol provides more aggressive caching
   strategies with inability to renew the following design goals:

   o    Compatibility with lease
   before expiration.  While this is considered a large range of server semantics.

   o    Provide rare or unusual event,
   the same caching benefits as previous versions of client must be prepared to recover.  Both the
        NFS protocol when unable server and client
   will be able to provide detect the more aggressive model.

   o    Requirements for aggressive caching failure to renew the lease and are organized so that a
        large portion capable
   of recovering without data corruption.  For the benefit can be obtained even when not all
        of server, it tracks the requirements can be met.

   The appropriate requirements
   last renewal event serviced for the server are discussed in later
   sections in client and knows when the lease
   will expire.  Similarly, the client must track operations which specific forms of caching are covered. (see will
   renew the
   section "Open Delegation").

9.2.  Delegation lease period.  Using the time that each such request was
   sent and Callbacks

   Recallable delegation of server responsibilities for a file to a the time that the corresponding reply was received, the
   client improves performance by avoiding repeated requests to should bound the
   server in time that the absence of inter-client conflict.  With corresponding renewal could
   have occurred on the use of a
   "callback" RPC from server to client, and thus determine if it is possible that
   a server recalls delegated
   responsibilities when another client engages in sharing lease period expiration could have occurred.

   The third lock revocation event can occur as a result of
   administrative intervention within the lease period.  While this is
   considered a
   delegated file.

   A delegation rare event, it is passed from possible that the server server's
   administrator has decided to release or revoke a particular lock held
   by the client, specifying the
   object client.  As a result of revocation, the delegation client will receive an
   error of NFS4ERR_EXPIRED and the type of delegation.  There are
   different types of delegations but each type contains a stateid to be
   used to represent error is received within the delegation when performing operations lease
   period for the lock.  In this instance the client may assume that
   depend on
   only the delegation.  This stateid is similar to those
   associated with lock_owner's locks and share reservations but differs in that have been lost.  The client notifies the
   stateid for a delegation is associated with a clientid and
   lock holder appropriately.  The client may be
   used on behalf not assume the lease
   period has been renewed as a result of all failed operation.

   When the nfs_lockowners for client determines the given client.  A
   delegation is made to lease period may have expired, the
   client must mark all locks held for the associated lease as a whole and not
   "unvalidated".  This means the client has been unable to any specific
   process re-establish
   or thread of control within it.

   Because callback RPCs may not work confirm the appropriate lock state with the server.  As described
   in all environments (due to
   firewalls, for example), correct protocol operation does not depend
   on them.  Preliminary testing of callback functionality by means of a
   CB_NULL procedure determines whether callbacks can be supported.  The
   CB_NULL procedure checks the continuity of previous section on crash recovery, there are scenarios in
   which the callback path.  A server makes a preliminary assessment of callback availability to may grant conflicting locks after the lease period
   has expired for a
   given client and avoids delegating responsibilities until client.  When it has
   determined is possible that callbacks are supported.  Because the granting of a
   delegation is always conditional upon lease period
   has expired, the absence of conflicting
   access, clients client must not assume validate each lock currently held to
   ensure that a delegation will be granted and
   they must always be prepared for OPENs to be processed without any

Draft Specification      NFS version 4 Protocol                July 2002

   delegations being conflicting lock has not been granted.

   Once granted, a delegation behaves in most ways like a lock.  There
   is an associated lease that is subject to renewal together with all
   of the other leases held The client may
   accomplish this task by that client.

   Unlike locks, issuing an operation by I/O request, either a second client to pending I/O
   or a delegated file
   will cause zero-length read, specifying the server to recall a delegation through a callback.

   On recall, stateid associated with the client holding
   lock in question. If the delegation must flush modified
   state (such as modified data) response to the server and return the
   delegation.  The conflicting request will not receive a response
   until the recall is complete.  The recall is considered complete when success, the
   client returns the delegation or the server times out on has validated all of the
   recall locks governed by that stateid and revokes
   re-established the delegation as a result of appropriate state between itself and the timeout.
   Following server.
   If the resolution I/O request is not successful, then one or more of the recall, the server has the
   information necessary to grant or deny locks
   associated with the second client's request.

   At stateid was revoked by the time server and the client receives
   must notify the owner.

8.9.  Share Reservations

   A share reservation is a delegation recall, it may have
   substantial state that needs to be flushed mechanism to the server.  Therefore,
   the server should allow sufficient time for the delegation control access to be
   returned since a file.  It
   is a separate and independent mechanism from record locking.  When a
   client opens a file, it may involve numerous RPCs issues an OPEN operation to the server.  If the server is able to determine that
   specifying the client is diligently flushing
   state to type of access required (READ, WRITE, or BOTH) and the server as a result
   type of access to deny others (deny NONE, READ, WRITE, or BOTH).  If

Draft Specification      NFS version 4 Protocol              August 2002

   the recall, OPEN fails the server may extend client will fail the usual time allowed for a recall.  However, application's open request.

   Pseudo-code definition of the time allowed for
   recall completion should not be unbounded.

   An example semantics:

                if ((request.access & file_state.deny)) ||
                      (request.deny & file_state.access))
                              return (NFS4ERR_DENIED)

   This checking of this is when responsibility to mediate opens share reservations on a given
   file OPEN is delegated to a client (see done with no exception
   for an existing OPEN for the section "Open Delegation"). same open_owner.

   The server will not know what opens are in effect on constants used for the client.
   Without this knowledge OPEN and OPEN_DOWNGRADE operations for the server will be unable
   access and deny fields are as follows:

   const OPEN4_SHARE_ACCESS_READ   = 0x00000001;
   const OPEN4_SHARE_ACCESS_WRITE  = 0x00000002;
   const OPEN4_SHARE_ACCESS_BOTH   = 0x00000003;

   const OPEN4_SHARE_DENY_NONE     = 0x00000000;
   const OPEN4_SHARE_DENY_READ     = 0x00000001;
   const OPEN4_SHARE_DENY_WRITE    = 0x00000002;
   const OPEN4_SHARE_DENY_BOTH     = 0x00000003;

8.10.  OPEN/CLOSE Operations

   To provide correct share semantics, a client MUST use the OPEN
   operation to determine if obtain the initial filehandle and indicate the desired
   access and deny state what if any access to deny.  Even if the client intends to
   use a stateid of all 0's or all 1's, it must still obtain the
   filehandle for the regular file allows any particular with the OPEN operation so the
   appropriate share semantics can be applied.  For clients that do not
   have a deny mode built into their open until programming interfaces, deny
   equal to NONE should be used.

   The OPEN operation with the delegation CREATE flag, also subsumes the CREATE
   operation for regular files as used in previous versions of the file has been returned.

   A client failure or NFS
   protocol.  This allows a network partition can result in failure to
   respond create with a share to be done atomically.

   The CLOSE operation removes all share reservations held by the
   lock_owner on that file.  If record locks are held, the client SHOULD
   release all locks before issuing a recall callback. In this case, CLOSE.  The server MAY free all
   outstanding locks on CLOSE but some servers may not support the CLOSE
   of a file that still has record locks held.  The server will revoke MUST return
   failure, NFS4ERR_LOCKS_HELD, if any locks would exist after the delegation which in turn
   CLOSE.

   The LOOKUP operation will render useless return a filehandle without establishing
   any modified lock state
   still on the client.

9.2.1.  Delegation Recovery

   There are three situations that delegation recovery must deal with:

   o    Client reboot or restart

   o    Server reboot or restart

   o    Network partition (full or callback-only)

   In server.  Without a valid stateid, the event server
   will assume the client reboots or restarts, has the failure to renew least access.  For example, a file
   opened with deny READ/WRITE cannot be accessed using a filehandle

Draft Specification      NFS version 4 Protocol                July              August 2002

   leases will result in the revocation

   obtained through LOOKUP because it would not have a valid stateid
   (i.e. using a stateid of record locks all bits 0 or all bits 1).

8.10.1.  Close and share
   reservations.  Delegations, however, may be treated Retention of State Information

   Since a bit
   differently.

   There will be situations in which delegations will need to be
   reestablished after CLOSE operation requests deallocation of a client reboots or restarts.  The reason for
   this is stateid, dealing
   with retransmission of the client CLOSE, may have file data stored locally and this data
   was associated with pose special difficulties,
   since the previously held delegations.  The client will
   need state information, which normally would be used to reestablish
   determine the appropriate file state on of the server.

   To allow for open file being designated, might be
   deallocated, resulting in an NFS4ERR_BAD_STATEID error.

   Servers may deal with this type problem in a number of client recovery, ways.  To provide
   the greatest degree assurance that the protocol is being used
   properly, a server may extend should, rather than deallocate the
   period for delegation recovery beyond stateid, mark
   it as close-pending, and retain the typical lease expiration
   period.  This implies that requests from other clients that conflict stateid with these delegations will need to wait.  Because the normal recall
   process may require significant time for this status, until
   later deallocation.  In this way, a retransmitted CLOSE can be
   recognized since the client stateid points to flush changed state to the server, other clients need information with this
   distinctive status, so that it can be prepared handled without error.

   When adopting this strategy, a server should retain the state
   information until the earliest of:

   o    Another validly sequenced request for delays the same lockowner, that
   occur because of
        is not a conflicting delegation.  This longer interval
   would increase retransmission.

   o    The time that a lockowner is freed by the window for clients server due to reboot and consult stable
   storage so that period
        with no activity.

   o    All locks for the delegations can be reclaimed.  For open
   delegations, such delegations client are reclaimed using OPEN with freed as a claim
   type result of CLAIM_DELEGATE_PREV.  (See a SETCLIENTID.

   Servers may avoid this complexity, at the sections on "Data Caching and
   Revocation" and "Operation 18: OPEN" for discussion cost of open
   delegation and less complete
   protocol error checking, by simply responding NFS4_OK in the details event of OPEN respectively).
   a CLOSE for a deallocated stateid, on the assumption that this case
   must be caused by a retranmitted close.  When adopting this approach,
   it is desirable to at least log an error when returning a no-error
   indication in this situation.  If the server reboots or restarts, delegations are reclaimed (using maintains a reply-cache
   mechanism, it can verify the OPEN operation with CLAIM_DELEGATE_PREV) in CLOSE is indeed a similar fashion to
   record locks retransmission and share reservations.  However, there
   avoid error logging in most cases.

8.11.  Open Upgrade and Downgrade

   When an OPEN is done for a slight
   semantic difference.  In the normal case if file and the server decides that a
   delegation should not be granted, it performs lockowner for which the requested action
   (e.g. OPEN) without granting any delegation.  For reclaim, open
   is being done already has the server
   grants file open, the delegation but a special designation result is applied so that to upgrade the client treats
   open file status maintained on the delegation as having been granted but recalled
   by server to include the server.  Because of this, access and
   deny bits specified by the client has new OPEN as well as those for the duty to write all
   modified state to existing
   OPEN.  The result is that there is one open file, as far as the server
   protocol is concerned, and then return it includes the delegation.  This
   process of handling delegation reclaim reconciles three principles union of the NFS Version 4 protocol:

   o    Upon reclaim, a client reporting resources assigned to it by an
        earlier server instance must be granted those resources.

   o    The server has unquestionable authority to determine whether
        delegations are to be granted and, once granted, whether they
        are to be continued.

   o    The use access and
   deny bits for all of callbacks is not to be depended upon until the client
        has proven its ability to receive them.

   When OPEN requests completed.  Only a network partition occurs, delegations are subject to freeing
   by the server when the lease renewal period expires.  This is similar single
   CLOSE will be done to reset the behavior for locks and share reservations.  For delegations,
   however, the server may extend the period in which conflicting effects of both OPEN's.  Note that

Draft Specification      NFS version 4 Protocol                July              August 2002

   requests are held off.  Eventually the occurrence of a conflicting
   request from another client will cause revocation of the delegation.
   A loss of the callback path (e.g. by later network configuration
   change) will have the same effect.  A recall request will fail and
   revocation of

   the delegation will result.

   A client normally finds out about revocation of a delegation client, when it
   uses a stateid associated with a delegation and receives issuing the error
   NFS4ERR_EXPIRED.  It also OPEN, may find out about delegation revocation
   after a client reboot when it attempts to reclaim a delegation and
   receives not know that the same error.  Note that file is
   in fact being opened.  The above only applies if both OPEN's result
   in the case of a revoked write
   open delegation, there are issues because data may have been modified OPEN'ed object being designated by the client whose delegation is revoked and separately by other
   clients.  See same filehandle.

   When the section "Revocation Recovery for Write Open
   Delegation" for a discussion server chooses to export multiple filehandles corresponding
   to the same file object and returns different filehandles on two
   different OPEN's of such issues.  Note also that when
   delegations are revoked, information about the revoked delegation
   will be written by same file object, the server to stable storage (as described in MUST NOT "OR"
   together the
   section "Crash Recovery").  This is done to deal with access and deny bits and coalesce the two open files.
   Instead the case in
   which a server reboots after revoking a delegation but before must maintain separate OPEN's with separate
   stateid's and will require separate CLOSE's to free them.

   When multiple open files on the client holding are merged into a single open
   file object on the revoked delegation is notified about server, the
   revocation.

9.3.  Data Caching

   When applications share access to a set close of files, they need to be
   implemented so as to take account one of the possibility open files (on the
   client) may necessitate change of conflicting the access by another application. and deny status of the
   open file on the server.  This is true whether because the applications
   in question execute on different clients or reside on union of the same
   client.

   Share reservations access and record locks are the facilities
   deny bits for the NFS
   version 4 protocol provides remaining open's may be smaller (i.e. a proper
   subset) than previously.  The OPEN_DOWNGRADE operation is used to allow applications
   make the necessary change and the client should use it to coordinate
   access by providing mutual exclusion facilities.  The NFS version 4
   protocol's data caching must be implemented such that it does not
   invalidate the assumptions that those using these facilities depend
   upon.

9.3.1.  Data Caching and OPENs

   In order to avoid invalidating update the sharing assumptions
   server so that
   applications rely on, NFS version 4 share reservation requests by other clients should not provide cached
   data to applications or modify it on behalf of an application when it
   would not be valid to obtain or modify that same data via a READ or
   WRITE operation.

   Furthermore, in the absence of open delegation (see the section "Open
   Delegation") two additional rules apply.  Note that these rules are
   obeyed in practice by many NFS version 2
   handled properly.

8.12.  Short and version 3 clients.

   o    First, cached data present on a client must be revalidated after

Draft Specification      NFS version 4 Protocol                July 2002

        doing an OPEN.  This is to ensure that Long Leases

   When determining the data time period for the OPENed
        file is still correctly reflected in server lease, the client's cache.  This
        validation must be done usual
   lease tradeoffs apply.  Short leases are good for fast server
   recovery at least when the client's OPEN
        operation includes DENY=WRITE or BOTH thus terminating a period
        in which other clients may have had the opportunity to open the
        file with WRITE access.  Clients may choose cost of increased RENEW or READ (with zero length)
   requests.  Longer leases are certainly kinder and gentler to do the
        revalidation more often (i.e. at OPENs specifying DENY=NONE) servers
   trying to
        parallel the NFS version 3 protocol's practice for the benefit handle very large numbers of users assuming this degree clients.  The number of cache revalidation.

   o    Second, modified data must be flushed RENEW
   requests drop in proportion to the lease time.  The disadvantages of
   long leases are slower recovery after server failure (server must
   wait for leases to expire and grace period before
        closing a granting new lock
   requests) and increased file OPENed contention (if client fails to transmit
   an unlock request then server must wait for write.  This lease expiration before
   granting new locks).

   Long leases are usable if the server is complementary able to store lease state in
   non-volatile memory.  Upon recovery, the
        first rule.  If server can reconstruct the data is
   lease state from its non-volatile memory and continue operation with
   its clients and therefore long leases would not flushed at CLOSE, be an issue.

8.13.  Clocks, Propagation Delay, and Calculating Lease Expiration

   To avoid the
        revalidation done after client OPENs as file is unable to
        achieve its purpose.  The other aspect to flushing need for synchronized clocks, lease times are granted by
   the data
        before close server as a time delta.  However, there is a requirement that the data must be committed to stable
        storage, at
   client and server clocks do not drift excessively over the server, before duration
   of the CLOSE operation lock.  There is requested
        by the client.  In also the case issue of a server reboot or restart and a
        CLOSEd file, it may not be possible to retransmit propagation delay across the data to
   network which could easily be
        written to several hundred milliseconds as well as
   the file.  Hence, this requirement.

9.3.2.  Data Caching and File Locking

   For those applications possibility that choose to use file locking instead of
   share reservations to exclude inconsistent file access, there is an
   analogous set of constraints that apply requests will be lost and need to be
   retransmitted.

Draft Specification      NFS version 4 Protocol              August 2002

   To take propagation delay into account, the client side data caching.
   These rules are effective only should subtract it
   from lease times (e.g. if the file locking is used in a way
   that matches in an equivalent way client estimates the actual READ and WRITE
   operations executed.  This is one-way
   propagation delay as opposed to file locking 200 msec, then it can assume that the lease is
   based on pure convention.  For example,
   already 200 msec old when it is possible gets it).  In addition, it will take
   another 200 msec to manipulate get a two-megabyte file by dividing the file into two one-megabyte
   regions and protecting access response back to the two regions by file locks on
   bytes zero and one.  A lock for write on byte zero of the file would
   represent the right to do READ and WRITE operations on server.  So the first
   region.  A client
   must send a lock for renewal or write on byte one of the file would represent the
   right data back to do READ and WRITE operations on the second region.  As long
   as all applications manipulating the file obey this convention, they
   will work on a local file system.  However, they may not work with server 400 msec
   before the NFS version 4 protocol unless clients refrain from data caching. lease would expire.

   The rules for data caching in server's lease period configuration should take into account the file locking environment are:

   o    First, when a client obtains a file lock for a particular
        region,
   network distance of the data cache corresponding to clients that region (if any
        cache data exists) must will be revalidated.  If accessing the change attribute
        indicates server's
   resources.  It is expected that the file may have been updated since the cached
        data was obtained, the client must flush or invalidate lease period will take into
   account the
        cached data network propogation delays and other network delay
   factors for the newly locked region.  A client might choose
        to invalidate all of non-modified cached data that it has for
        the file but population.  Since the only requirement protocol does not allow
   for correct operation is an automatic method to
        invalidate all of determine an appropriate lease period, the data in
   server's administrator may have to tune the newly locked region.

Draft Specification      NFS version 4 Protocol                July 2002

   o    Second, before releasing a write lock lease period.

8.14.  Migration, Replication and State

   When responsibility for handling a region, all modified
        data for that region must be flushed given file system is transferred
   to a new server (migration) or the server.  The
        modified data must also be written client chooses to stable storage.

   Note that flushing data use an alternate
   server (e.g. in response to the server and unresponsiveness) in the invalidation context
   of cached
   data must reflect file system replication, the actual byte ranges locked or unlocked.
   Rounding these up or down to reflect client cache block boundaries
   will cause problems if not carefully done.  For example, writing a
   modified block when only half appropriate handling of that block is within an area being
   unlocked may cause invalid modification to the region outside state shared
   between the
   unlocked area.  This, in turn, may be part client and server (i.e. locks, leases, stateid's, and
   clientid's) is as described below.  The handling differs between
   migration and replication.  For related discussion of a region locked by
   another client.  Clients can avoid this situation by synchronously
   performing portions file server
   state and recover of write operations that overlap that portion
   (initial such see the sections under "File Locking and
   Share Reservations"

   If server replica or final) that is not a full block.  Similarly, invalidating server immigrating a locked area which filesystem agrees to, or
   is not an integral number of full buffer blocks
   would require expected to, accept opaque values from the client that originated
   from another server, then it is a wise implementation practice for
   the servers to read one encode the "opaque" values in network byte order. This
   way, servers acting as replicas or two partial blocks immigrating filesystems will be
   able to parse values like stateids, directory cookies, filehandles,
   etc. even if their native byte order is different from other servers
   cooperating in the
   server if replication and migration of the revalidation procedure shows that filesystem.

8.14.1.  Migration and State

   In the data which case of migration, the
   client possesses may not be valid.

   The data that is written to servers involved in the server as migration of a pre-requisite
   filesystem SHOULD transfer all server state from the original to the
   unlocking of a region
   new server.  This must be written, at the server, to stable
   storage.  The client may accomplish this either with synchronous
   writes or by following asynchronous writes with done in a COMMIT operation.
   This way that is required because retransmission of transparent to the modified data after a
   server reboot might conflict with a lock held by another
   client.

   A  This state transfer will ease the client's transition when a
   filesystem migration occurs.  If the servers are successful in
   transferring all state, the client implementation may choose will continue to accommodate applications which use record locking in non-standard ways (e.g. using a record lock as
   a global semaphore) stateid's
   assigned by flushing to the original server.  Therefore the new server more data upon must
   recognize these stateid's as valid.  This holds true for the clientid
   as well.  Since responsibility for an LOCKU
   than entire filesystem is covered by
   transferred with a migration event, there is no possibility that
   conflicts will arise on the locked range.  This may include modified data
   within files other than new server as a result of the one for which transfer of

Draft Specification      NFS version 4 Protocol              August 2002

   locks.

   As part of the unlocks are transfer of information between servers, leases would
   be transferred as well.  The leases being done.
   In such cases, transferred to the client must not interfere with applications whose
   READs and WRITEs are being done only within new
   server will typically have a different expiration time from those for
   the bounds of record
   locks which same client, previously on the application holds.  For example, an application locks old server.  To maintain the
   property that all leases on a single byte of given server for a file and proceeds to write that single byte.  A given client that chose to handle a LOCKU by flushing all modified data to expire
   at the same time, the server could validly write that single byte in response to an
   unrelated unlock.  However, it would not be valid to write should advance the entire
   block in which that single written byte was located since it includes
   an area that is not locked and might be locked by another client.
   Client implementations can avoid this problem by dividing files with
   modified data into those for which all modifications are done expiration time to
   areas covered by an appropriate record lock and those for which there
   are modifications not covered by a record lock.  Any writes done for
   the former class of files must not include areas not locked and thus
   not modified on
   the client.

9.3.3.  Data Caching and Mandatory File Locking

   Client side data caching needs to respect mandatory file locking when
   it is in effect.  The presence later of mandatory file locking for a given

Draft Specification      NFS version 4 Protocol                July 2002

   file is indicated in the result flags for an OPEN.  When mandatory
   locking is in effect for a file, the client must check for an
   appropriate file lock for data leases being read transferred or written.  If a lock
   exists for the range being read or written, leases already
   present.  This allows the client to maintain lease renewal of both
   classes without special effort.

   The servers may satisfy
   the request using the client's validated cache.  If an appropriate
   file lock is choose not held for the range of to transfer the read or write, state information upon
   migration.  However, this choice is discouraged.  In this case, when
   the read or
   write request must not be satisfied by client presents state information from the client's cache and original server, the
   request
   client must be sent prepared to the server for processing.  When a read receive either NFS4ERR_STALE_CLIENTID or
   write request partially overlaps a locked region,
   NFS4ERR_STALE_STATEID from the request new server.  The client should
   be subdivided into multiple pieces with each region (locked or not)
   treated appropriately.

9.3.4.  Data Caching and File Identity

   When clients cache data, the file data needs then
   recover its state information as it normally would in response to organized according a
   server failure.  The new server must take care to allow for the file system object to which
   recovery of state information as it would in the data belongs.  For NFS version
   3 clients, event of server
   restart.

8.14.2.  Replication and State

   Since client switch-over in the typical practice has been to assume for case of replication is not under
   server control, the purpose handling of
   caching that distinct filehandles represent distinct file system
   objects. state is different.  In this case,
   leases, stateid's and clientid's do not have validity across a
   transition from one server to another.  The client then has must re-establish
   its locks on the choice new server.  This can be compared to organize and maintain the
   data cache on this basis.

   In the NFS version 4 protocol, there re-
   establishment of locks by means of reclaim-type requests after a
   server reboot.  The difference is now that the possibility server has no provision to have
   significant deviations
   distinguish requests reclaiming locks from those obtaining new locks
   or to defer the latter.  Thus, a "one filehandle per object" model
   because client re-establishing a filehandle may be constructed lock on the basis
   new server (by means of the object's
   pathname.  Therefore, clients need a reliable method to determine if
   two filehandles designate LOCK or OPEN request), may have the same file system object.  If clients
   were simply
   requests denied due to assume that all distinct filehandles denote distinct
   objects and proceed a conflicting lock.  Since replication is
   intended for read-only use of filesystems, such denial of locks
   should not pose large difficulties in practice.  When an attempt to do data caching
   re-establish a lock on this basis, caching
   inconsistencies would arise between a new server is denied, the distinct client side objects
   which mapped to the same server side object.

   By providing a method to differentiate filehandles, should
   treat the NFS version 4
   protocol alleviates a potential functional regression in comparison
   with situation as if his original lock had been revoked.

8.14.3.  Notification of Migrated Lease

   In the NFS version 3 protocol.  Without this method, caching
   inconsistencies within case of lease renewal, the same client could occur and this has may not
   been present in previous versions of the NFS protocol.  Note be submitting
   requests for a filesystem that it
   is possible has been migrated to have such inconsistencies with applications executing
   on multiple clients but that is not the issue being addressed here.

   For the purposes another server.
   This can occur because of data caching, the following steps allow an NFS
   version 4 implicit lease renewal mechanism.  The
   client renews leases for all filesystems when submitting a request to determine whether two distinct filehandles denote
   the same server side object:

   o    If GETATTR directed to two filehandles have different values of
        the fsid attribute, then
   any one filesystem at the filehandles represent distinct
        objects.

   o    If GETATTR server.

   In order for any file with an fsid that matches the fsid client to schedule renewal of leases that may have
   been relocated to the two filehandles in question returns a unique_handles
        attribute with a value of TRUE, then new server, the two objects are client must find out about

Draft Specification      NFS version 4 Protocol                July              August 2002

        distinct.

   o    If GETATTR directed to the two filehandles does not

   lease relocation before those leases expire.  To accomplish this, all
   operations which implicitly renew leases for a client (i.e. OPEN,
   CLOSE, READ, WRITE, RENEW, LOCK, LOCKT, LOCKU), will return the
        fileid attribute error
   NFS4ERR_LEASE_MOVED if responsibility for one or both any of the handles, then it cannot
        be determined whether the two objects are the same.  Therefore,
        operations which depend on that knowledge (e.g. client side data
        caching) cannot leases to be done reliably.

   o    If GETATTR directed
   renewed has been transferred to a new server.  This condition will
   continue until the two filehandles returns different
        values for client receives an NFS4ERR_MOVED error and the fileid attribute, then they are distinct objects.

   o    Otherwise they are
   server receives the same object.

9.4.  Open Delegation subsequent GETATTR(fs_locations) for an access to
   each filesystem for which a lease has been moved to a new server.

   When a file is being OPENed, client receives an NFS4ERR_LEASE_MOVED error, it should
   perform some operation, such as a RENEW, on each filesystem
   associated with the server may delegate further handling
   of opens and closes for that file to in question.  When the opening client.  Any such
   delegation is recallable, since client receives an
   NFS4ERR_MOVED error, the circumstances that allowed for client can follow the delegation are subject normal process to change.  In particular, the server may
   receive a conflicting OPEN from another client,
   obtain the new server must
   recall information (through the delegation before deciding whether fs_locations
   attribute) and perform renewal of those leases on the OPEN new server.  If
   the server has not had state transferred to it transparently, the
   client will receive either NFS4ERR_STALE_CLIENTID or
   NFS4ERR_STALE_STATEID from the other new server, as described above, and
   the client may be granted.  Making a delegation is up to can then recover state information as it does in the event
   of server failure.

8.14.4.  Migration and
   clients should not assume the Lease_time Attribute

   In order that any particular OPEN either will or
   will not result the client may appropriately manage its leases in an open delegation.  The following is a typical
   set the
   case of conditions migration, the destination server must establish proper
   values for the lease_time attribute.

   When state is transferred transparently, that servers might use in deciding whether OPEN state should be delegated:

   o include
   the correct value of the lease_time attribute.  The client lease_time
   attribute on the destination server must never be able to respond less than that on
   the source since this would result in premature expiration of leases
   granted by the source server.  Upon migration in which state is
   transferred transparently, the client is under no obligation to re-
   fetch the server's callback
        requests.  The server will lease_time attribute and may continue to use the CB_NULL procedure for a test
        of callback ability.

   o    The value
   previously fetched (on the source server).

   If state has not been transferred transparently (i.e. the client must have responded properly to previous recalls.

   o    There must be no current open conflicting with sees
   a real or simulated server reboot), the requested
        delegation.

   o    There client should be no current delegation that conflicts with fetch the
        delegation being requested.

   o    The probability value
   of future conflicting open requests should be
        low based lease_time on the recent history of new (i.e. destination) server, and use it for
   subsequent locking requests.  However the file.

   o    The existence of any server-specific semantics of OPEN/CLOSE
        that would make server must respect a grace
   period at least as long as the required handling incompatible with lease_time on the
        prescribed handling source server, in
   order to ensure that the delegated client would apply (see
        below).

   There clients have ample time to reclaim their locks
   before potentially conflicting non-reclaimed locks are two types granted.  The
   means by which the new server obtains the value of open delegations, read and write.  A read open
   delegation allows a client to handle, lease_time on its own, requests to open a
   file for reading that do not deny read access the
   old server is left to others.  Multiple
   read open delegations may be outstanding simultaneously and do the server implementations.  It is not
   specified by the NFS version 4 protocol.

Draft Specification      NFS version 4 Protocol                July              August 2002

   conflict.  A write open delegation allows the client to handle, on
   its own, all opens.  Only one write open delegation may exist for a
   given

9.  Client-Side Caching

   Client-side caching of data, of file at a given time attributes, and it of file names is inconsistent
   essential to providing good performance with any read open
   delegations.

   When a client has the NFS protocol.
   Providing distributed cache coherence is a read open delegation, it may difficult problem and
   previous versions of the NFS protocol have not make any changes attempted it.
   Instead, several NFS client implementation techniques have been used
   to reduce the contents or attributes problems that a lack of the file but coherence poses for users.
   These techniques have not been clearly defined by earlier protocol
   specifications and it is assured that no
   other client may do so.  When a often unclear what is valid or invalid
   client has a write open delegation, behavior.

   The NFS version 4 protocol uses many techniques similar to those that
   have been used in previous protocol versions.  The NFS version 4
   protocol does not provide distributed cache coherence.  However, it may modify the file data since no other client will
   defines a more limited set of caching guarantees to allow locks and
   share reservations to be accessing
   the file's data.  The used without destructive interference from
   client holding side caching.

   In addition, the NFS version 4 protocol introduces a write delegation may only
   affect file attributes
   mechanism which are intimately connected with the file
   data:  size, time_modify, change.

   When a client has an open delegation, it does not send OPENs or
   CLOSEs to allows many decisions normally made by the server but updates the appropriate status internally.
   For a read open delegation, opens that cannot to
   be handled made locally
   (opens for write or that deny read access) must be sent to by clients.  This mechanism provides efficient
   support of the
   server.

   When an open delegation common cases where sharing is made, the response to the OPEN contains an
   open delegation structure which specifies the following:

   o    the type of delegation (read infrequent or write)

   o    space limitation information to control flushing where
   sharing is read-only.

9.1.  Performance Challenges for Client-Side Caching

   Caching techniques used in previous versions of data on
        close (write open delegation only, see the section "Open
        Delegation and Data Caching")

   o    an nfsace4 specifying read and write permissions

   o    a stateid to represent NFS protocol have
   been successful in providing good performance.  However, several
   scalability challenges can arise when those techniques are used with
   very large numbers of clients.  This is particularly true when
   clients are geographically distributed which classically increases
   the delegation latency for READ and WRITE cache revalidation requests.

   The stateid is separate and distinct from previous versions of the stateid for NFS protocol repeat their file data
   cache validation requests at the OPEN
   proper.  The standard stateid, unlike time the delegation stateid, file is
   associated with a particular nfs_lockowner and will continue to be
   valid after the delegation opened.  This
   behavior can have serious performance drawbacks.  A common case is recalled and the
   one in which a file remains open.

   When is only accessed by a request internal single client.  Therefore,
   sharing is infrequent.

   In this case, repeated reference to the client server to find that no
   conflicts exist is made expensive.  A better option with regards to open
   performance is to allow a client that repeatedly opens a file and open
   delegation to do
   so without reference to the server.  This is done until potentially
   conflicting operations from another client actually occur.

   A similar situation arises in effect, it will be accepted or rejected solely on connection with file locking.  Sending
   file lock and unlock requests to the basis of server as well as the following conditions.  Any requirement for other
   checks read and
   write requests necessary to be made by make data caching consistent with the delegate should result in open delegation
   being denied so that the checks can be made by the server itself.

   o    The access and deny bits for the request and the file as
        described in
   locking semantics (see the section "Share Reservations".

   o    The read "Data Caching and write permissions as determined below.

   The nfsace4 passed with delegation File Locking")
   can be severely limit performance.  When locking is used to avoid frequent
   ACCESS calls.  The permission check should be as follows: provide

Draft Specification      NFS version 4 Protocol                July              August 2002

   o    If the nfsace4 indicates that the open may be done, then it
        should be granted without reference to the server.

   o    If the nfsace4 indicates that the open may not be done, then an
        ACCESS request must be sent to the server to obtain the
        definitive answer.

   The server may return an nfsace4 that

   protection against infrequent conflicts, a large penalty is more restrictive than the
   actual ACL of the file. incurred.
   This includes an nfsace4 that specifies
   denial of all access.  Note that some common practices such as
   mapping the traditional user "root" to the user "nobody" penalty may make it
   incorrect to return discourage the actual ACL use of the file in the delegation
   response. locking by applications.

   The use of delegation together with various other forms of NFS version 4 protocol provides more aggressive caching
   creates
   strategies with the possibility that no server authentication will ever be
   performed for following design goals:

   o    Compatibility with a given user since all large range of server semantics.

   o    Provide the user's requests might be
   satisfied locally.  Where the client is depending on same caching benefits as previous versions of the server for
   authentication,
        NFS protocol when unable to provide the client should be sure authentication occurs more aggressive model.

   o    Requirements for
   each user by use aggressive caching are organized so that a
        large portion of the ACCESS operation.  This should benefit can be the case obtained even if an ACCESS operation would when not all
        of the requirements can be required otherwise.  As
   mentioned before, met.

   The appropriate requirements for the server may enforce frequent authentication by
   returning an nfsace4 denying all access with every open delegation.

9.4.1.  Open are discussed in later
   sections in which specific forms of caching are covered. (see the
   section "Open Delegation").

9.2.  Delegation and Data Caching

   OPEN Callbacks

   Recallable delegation allows much of the message overhead associated with
   the opening and closing files server responsibilities for a file to be eliminated.  An open when an open
   delegation is in effect does not require that a validation message be
   sent
   client improves performance by avoiding repeated requests to the server.  The continued endurance
   server in the absence of inter-client conflict.  With the "read open
   delegation" provides use of a guarantee that no OPEN for write and thus no
   write has occurred.  Similarly,
   "callback" RPC from server to client, a server recalls delegated
   responsibilities when closing another client engages in sharing of a file opened for write
   and if write open
   delegated file.

   A delegation is in effect, passed from the data written does not
   have to be flushed server to the server until client, specifying the open delegation is
   recalled.  The continued endurance
   object of the open delegation provides a
   guarantee that no open and thus no read or write has been done by
   another client.

   For the purposes type of open delegation, READs and WRITEs done without an
   OPEN delegation.  There are treated as the functional equivalents
   different types of a corresponding delegations but each type of OPEN.  This refers contains a stateid to be
   used to represent the READs delegation when performing operations that
   depend on the delegation.  This stateid is similar to those
   associated with locks and WRITEs share reservations but differs in that use the
   special stateids consisting
   stateid for a delegation is associated with a clientid and may be
   used on behalf of all zero bits the open_owners for the given client.  A
   delegation is made to the client as a whole and not to any specific
   process or thread of control within it.

   Because callback RPCs may not work in all one bits.
   Therefore, READs or WRITEs with a special stateid done by another
   client will force the server environments (due to recall
   firewalls, for example), correct protocol operation does not depend
   on them.  Preliminary testing of callback functionality by means of a write open delegation.
   CB_NULL procedure determines whether callbacks can be supported.  The
   CB_NULL procedure checks the continuity of the callback path.  A
   WRITE with a special stateid done by another client will force
   server makes a
   recall preliminary assessment of read open delegations.

   With delegations, callback availability to a
   given client is able to avoid writing data to the
   server when and avoids delegating responsibilities until it has
   determined that callbacks are supported.  Because the CLOSE granting of a file is serviced.  The CLOSE operation
   delegation is always conditional upon the usual point at which the client is notified absence of conflicting
   access, clients must not assume that a lack of stable
   storage delegation will be granted and
   they must always be prepared for the modified file data generated by the application.  At OPENs to be processed without any

Draft Specification      NFS version 4 Protocol                July              August 2002

   the CLOSE, file data

   delegations being granted.

   Once granted, a delegation behaves in most ways like a lock.  There
   is written an associated lease that is subject to renewal together with all
   of the server and through normal
   accounting other leases held by that client.

   Unlike locks, an operation by a second client to a delegated file
   will cause the server is able to determine if recall a delegation through a callback.

   On recall, the available file
   system space for client holding the delegation must flush modified
   state (such as modified data) to the data has been exceeded (i.e. server returns
   NFS4ERR_NOSPC or NFS4ERR_DQUOT).  This accounting includes quotas. and return the
   delegation.  The introduction of delegations requires that conflicting request will not receive a alternative method be
   in place for response
   until the recall is complete.  The recall is considered complete when
   the same type of communication to occur between client
   and server.

   In returns the delegation response, or the server provides either times out on the limit of
   recall and revokes the size delegation as a result of the file or timeout.
   Following the number resolution of modified blocks and associated
   block size.  The the recall, the server must ensure that has the client will be able to
   flush data
   information necessary to grant or deny the server of second client's request.

   At the time the client receives a size equal to delegation recall, it may have
   substantial state that provided in needs to be flushed to the
   original delegation.  The server must make this assurance for all
   outstanding delegations. server.  Therefore,
   the server must be careful in
   its management of available space should allow sufficient time for new or modified data taking
   into account available file system space and any applicable quotas.
   The the delegation to be
   returned since it may involve numerous RPCs to the server.  If the
   server is able to determine that the client is diligently flushing
   state to the server can recall delegations as a result of managing the
   available file system space.  The client should abide by the server's
   state space limits for delegations.  If recall, the client exceeds server may extend
   the stated
   limits usual time allowed for a recall.  However, the delegation, the server's behavior time allowed for
   recall completion should not be unbounded.

   An example of this is undefined.

   Based when responsibility to mediate opens on server conditions, quotas or available file system space,
   the server may grant write open delegations with very restrictive
   space limitations.  The limitations may be defined in a way that will
   always force modified data to be flushed given
   file is delegated to a client (see the section "Open Delegation").
   The server will not know what opens are in effect on close.

   With respect to authentication, flushing modified data to the client.
   Without this knowledge the server
   after a CLOSE has occurred may will be problematic.  For example, unable to determine if the user
   of
   access and deny state for the application may have logged off of file allows any particular open until
   the delegation for the file has been returned.

   A client and unexpired
   authentication credentials may not be present. failure or a network partition can result in failure to
   respond to a recall callback. In this case, the server will revoke
   the delegation which in turn will render useless any modified state
   still on the client.

9.2.1.  Delegation Recovery

   There are three situations that delegation recovery must deal with:

   o    Client reboot or restart

   o    Server reboot or restart

   o    Network partition (full or callback-only)

   In the event the client may need to take special care reboots or restarts, the failure to ensure that local unexpired
   credentials renew

Draft Specification      NFS version 4 Protocol              August 2002

   leases will result in fact be available.  This may be accomplished by
   tracking the expiration time revocation of credentials record locks and flushing data well share
   reservations.  Delegations, however, may be treated a bit
   differently.

   There will be situations in
   advance of their expiration or by making private copies of
   credentials which delegations will need to assure their availability when needed.

9.4.2.  Open Delegation and File Locks

   When be
   reestablished after a client holds a write open delegation, lock operations are
   performed locally.  This includes those required reboots or restarts.  The reason for mandatory file
   locking.  This can be done since the delegation implies that there
   can be no conflicting locks.  Similarly, all of
   this is the revalidations
   that would normally be associated with obtaining locks client may have file data stored locally and the
   flushing of this data
   was associated with the releasing of locks need not be
   done.

9.4.3.  Recall of Open Delegation previously held delegations.  The following events necessitate recall of an open delegation:

Draft Specification      NFS version 4 Protocol                July 2002

   o    Potentially conflicting OPEN request (or READ/WRITE done with
        "special" stateid)

   o    SETATTR issued by another client

   o    REMOVE request for will
   need to reestablish the appropriate file

   o    RENAME request for state on the file as either source or target server.

   To allow for this type of client recovery, the
        RENAME

   Whether a RENAME of a directory in the path leading to server MAY extend the file
   results in recall of an open
   period for delegation depends on the semantics of recovery beyond the server file system.  If typical lease expiration
   period.  This implies that file system denies such RENAMEs when
   a file is open, the recall must be performed to determine whether the
   file in question is, in fact, open.

   In addition requests from other clients that conflict
   with these delegations will need to wait.  Because the situations above, the server may choose to normal recall
   open delegations at any
   process may require significant time if resource constraints make it
   advisable for the client to do so.  Clients should always flush changed
   state to the server, other clients need be prepared for the
   possibility delays that
   occur because of recall.

   The server needs to employ special handling for a GETATTR where conflicting delegation.  This longer interval
   would increase the
   target is a file window for clients to reboot and consult stable
   storage so that has a write open delegation in effect.  In this
   case, the client holding the delegation needs to delegations can be interrogated.
   The server will use reclaimed.  For open
   delegations, such delegations are reclaimed using OPEN with a CB_GETATTR callback, if the GETATTR attribute
   bits include any claim
   type of CLAIM_DELEGATE_PREV.  (See the attributes that a write open delegate may
   modify (size, time_modify, change).

   When a client receives a recall sections on "Data Caching and
   Revocation" and "Operation 18: OPEN" for an discussion of open delegation, it needs to
   update state on
   delegation and the details of OPEN respectively).

   A server before returning the delegation.  These
   same updates must be done whenever MAY support a client chooses to return claim type of CLAIM_DELEGATE_PREV, but if it
   does, it MUST NOT remove delegations upon SETCLIENTID_CONFIRM, and
   instead MUST, for a
   delegation voluntarily.  The following items period of time no less than that of state need to be
   dealt with:

   o    If the file associated with value of
   the delegation is no longer open and
        no previous CLOSE operation has been sent lease_time attribute, maintain the client's delegations to allow
   time for the server, a CLOSE
        operation must be sent client to issue CLAIM_DELEGATE_PREV requests. The server
   that supports CLAIM_DELEGATE_PREV MUST support the server.

   o    If a file has other open references at DELEGPURGE
   operation.

   When the server reboots or restarts, delegations are reclaimed (using
   the client, then OPEN
        operations must be sent operation with CLAIM_PREVIOUS) in a similar fashion to
   record locks and share reservations.  However, there is a slight
   semantic difference.  In the server.  The appropriate stateids
        will be provided by normal case if the server for subsequent use by the client
        since the decides that a
   delegation stateid will should not longer be valid.  These
        OPEN requests are done with granted, it performs the claim type of
        CLAIM_DELEGATE_CUR.  This will allow requested action
   (e.g. OPEN) without granting any delegation.  For reclaim, the presentation of server
   grants the delegation stateid but a special designation is applied so that
   the client can establish treats the
        appropriate rights to perform delegation as having been granted but recalled
   by the OPEN.  (see server.  Because of this, the section
        "Operation 18: OPEN" for details.)

   o    If there are granted file locks, client has the corresponding LOCK
        operations need duty to be performed.  This applies write all
   modified state to the write open
        delegation case only. server and then return the delegation.  This
   process of handling delegation reclaim reconciles three principles of
   the NFS version 4 protocol:

   o    Upon reclaim, a client reporting resources assigned to it by an
        earlier server instance must be granted those resources.

   o    The server has unquestionable authority to determine whether
        delegations are to be granted and, once granted, whether they
        are to be continued.

Draft Specification      NFS version 4 Protocol                July              August 2002

   o    For a write open delegation, if at the time    The use of recall the file callbacks is not open for write, all modified data for the file must be
        flushed to the server.  If the delegation had not existed, be depended upon until the client would have done this data flush before the CLOSE
        operation.

   o    For
        has proven its ability to receive them.

   When a write open delegation network partition occurs, delegations are subject to freeing
   by the server when a file the lease renewal period expires.  This is still open at similar
   to the
        time of recall, any modified data behavior for locks and share reservations.  For delegations,
   however, the file needs to be
        flushed to the server.

   o    With server may extend the write open delegation period in place, it is possible that the
        file was truncated during which conflicting
   requests are held off.  Eventually the duration occurrence of a conflicting
   request from another client will cause revocation of the delegation.  For
        example,
   A loss of the truncation could callback path (e.g. by later network configuration
   change) will have occurred as a result the same effect.  A recall request will fail and
   revocation of an
        OPEN UNCHECKED with a size attribute value the delegation will result.

   A client normally finds out about revocation of zero.  Therefore,
        if a truncation of the file has occurred delegation when it
   uses a stateid associated with a delegation and this operation has
        not been propagated to the server, receives the truncation must occur
        before any modified data is written error
   NFS4ERR_EXPIRED.  It also may find out about delegation revocation
   after a client reboot when it attempts to the server.

   In reclaim a delegation and
   receives that same error.  Note that in the case of a revoked write
   open delegation, file locking imposes some
   additional requirements.  The flushing of any modified there are issues because data in any
   region for which a write lock was released while may have been modified
   by the write open client whose delegation was in effect is what is required to precisely maintain revoked and separately by other
   clients.  See the associated invariant.  However, because section "Revocation Recovery for Write Open
   Delegation" for a discussion of such issues.  Note also that when
   delegations are revoked, information about the write open revoked delegation
   implies no other locking
   will be written by other clients, a simpler implementation
   is to flush all modified data for the file server to stable storage (as described just above)
   if any write lock has been released while the write open delegation
   was in effect.

9.4.4.  Delegation Revocation

   At the point
   section "Crash Recovery").  This is done to deal with the case in
   which a server reboots after revoking a delegation is revoked, if there are associated opens
   on but before the client,
   client holding the revoked delegation is notified about the
   revocation.

9.3.  Data Caching

   When applications holding these opens share access to a set of files, they need to be
   notified.  This notification usually occurs by returning errors for
   READ/WRITE operations or when a close is attempted for the open file.

   If no opens exist for the file at the point the delegation is
   revoked, then notification
   implemented so as to take account of the revocation is unnecessary.
   However, if there possibility of conflicting
   access by another application.  This is modified data present at true whether the client for applications
   in question execute on different clients or reside on the
   file, same
   client.

   Share reservations and record locks are the user of facilities the application should be notified.  Unfortunately,
   it may not be possible NFS
   version 4 protocol provides to notify the user since active allow applications
   may not to coordinate
   access by providing mutual exclusion facilities.  The NFS version 4
   protocol's data caching must be present at the client.  See implemented such that it does not
   invalidate the section "Revocation
   Recovery for Write Open Delegation" for additional details.

9.5. assumptions that those using these facilities depend
   upon.

9.3.1.  Data Caching and Revocation

   When locks and delegations are revoked, OPENs

   In order to avoid invalidating the sharing assumptions upon which
   successful caching depend are no longer guaranteed.  The owner of the
   locks or share reservations which have been revoked needs that
   applications rely on, NFS version 4 clients should not provide cached
   data to be
   notified.  This notification includes applications with a file open or modify it on behalf of an application when it
   would not be valid to obtain or modify that has same data via a corresponding delegation which has been revoked.  Cached READ or

Draft Specification      NFS version 4 Protocol                July              August 2002

   data associated with the revocation must be removed from the client.
   In

   WRITE operation.

   Furthermore, in the case absence of modified data existing in open delegation (see the client's cache, section "Open
   Delegation") two additional rules apply.  Note that these rules are
   obeyed in practice by many NFS version 2 and version 3 clients.

   o    First, cached data present on a client must be removed from revalidated after
        doing an OPEN. Revalidating means that the client without it being written to fetches the
   server.  As mentioned,
        change attribute from the assumptions made by server, compares it with the client are no
   longer valid at cached
        change attribute, and if different, declares the point when a lock or delegation has been revoked.
   For example, another client may have been granted a conflicting lock
   after cached data (as
        well as the revocation of cached attributes) as invalid.  This is to ensure
        that the lock at data for the first client.  Therefore, OPENed file is still correctly reflected
        in the
   data within client's cache.  This validation must be done at least
        when the lock range client's OPEN operation includes DENY=WRITE or BOTH
        thus terminating a period in which other clients may have been modified by the other
   client.  Obviously, had
        the first client is unable opportunity to guarantee open the file with WRITE access.  Clients may
        choose to do the
   application what has occurred revalidation more often (i.e. at OPENs
        specifying DENY=NONE) to parallel the file in NFS version 3 protocol's
        practice for the case benefit of revocation.

   Notification to a lock owner will in many cases consist users assuming this degree of simply
   returning an error on cache
        revalidation.

        Since the next change attribute is updated for data and all subsequent READs/WRITEs metadata
        modifications, some client implementors may be tempted to use
        the
   open file or on the close.  Where the methods available time_modify attribute and not change to a client
   make such notification impossible because errors for certain
   operations may validate cached
        data, so that metadata changes do not be returned, more drastic action such as signals
   or process termination may be appropriate. spuriously invalidate
        clean data.  The justification for implementor is cautioned in this approach. The
        change attribute is that an invariant for which an application depends on may be
   violated.  Depending on how errors are typically treated guaranteed to change for each update to the
   client operating environment, further levels of notification
   including logging, console messages, and GUI pop-ups may be
   appropriate.

9.5.1.  Revocation Recovery for Write Open Delegation

   Revocation recovery for a write open delegation poses
        file, whereas time_modify is guaranteed to change only at the special
   issue
        granularity of modified data in the client cache while time_delta attribute. Use by the file is client's
        data cache validation logic of time_modify and not
   open.  In this situation, any change runs
        the risk of the client which does not flush incorrectly marking stale data as valid.

   o    Second, modified data must be flushed to the server on each close must ensure that the user receives
   appropriate notification of the failure as before
        closing a result of the
   revocation.  Since such situations may require human action file OPENed for write.  This is complementary to
   correct problems, notification schemes in which the appropriate user
   or administrator is notified may be necessary.  Logging and console
   messages are typical examples.
        first rule.  If there is modified data on the client, it must data is not be flushed
   normally to at CLOSE, the server.  A
        revalidation done after client may attempt to provide a copy of
   the file data OPENs as modified during the delegation under a different
   name in the file system name space is unable to ease recovery.  Unless
        achieve its purpose.  The other aspect to flushing the
   client can determine data
        before close is that the file has not modified by any other
   client, this technique data must be limited committed to situations in which a
   client has a complete cached copy of stable
        storage, at the file in question.  Use server, before the CLOSE operation is requested
        by the client.  In the case of
   such a technique may be limited to files under a certain size server reboot or restart and a
        CLOSEd file, it may
   only not be used when sufficient disk space is guaranteed possible to retransmit the data to be available
   within
        written to the target file system file.  Hence, this requirement.

9.3.2.  Data Caching and when the client has sufficient
   buffering resources File Locking

   For those applications that choose to keep the cached copy available until it use file locking instead of
   share reservations to exclude inconsistent file access, there is
   properly stored an
   analogous set of constraints that apply to client side data caching.
   These rules are effective only if the target file system. locking is used in a way
   that matches in an equivalent way the actual READ and WRITE

Draft Specification      NFS version 4 Protocol                July              August 2002

9.6.  Attribute Caching

   The attributes discussed in this section do not include named
   attributes.  Individual named attributes are analogous to files and
   caching of the data for these needs to be handled just as data
   caching

   operations executed.  This is for ordinary files.  Similarly, LOOKUP results from an
   OPENATTR directory are as opposed to be cached file locking that is
   based on the same basis as any other
   pathnames and similarly for directory contents.

   Clients may cache file attributes obtained from the server and use
   them to avoid subsequent GETATTR requests.  Such caching pure convention.  For example, it is write
   through in that modification possible to manipulate
   a two-megabyte file attributes is always done by
   means of requests dividing the file into two one-megabyte
   regions and protecting access to the server two regions by file locks on
   bytes zero and should not be done locally one.  A lock for write on byte zero of the file would
   represent the right to do READ and
   cached.  The exception WRITE operations on the first
   region.  A lock for write on byte one of the file would represent the
   right to do READ and WRITE operations on the second region.  As long
   as all applications manipulating the file obey this are modifications to attributes that
   are intimately connected convention, they
   will work on a local filesystem.  However, they may not work with the
   NFS version 4 protocol unless clients refrain from data caching.  Therefore, extending

   The rules for data caching in the file locking environment are:

   o    First, when a client obtains a file by writing data to lock for a particular
        region, the local data cache is reflected immediately
   in corresponding to that region (if any
        cache data exists) must be revalidated.  If the size as seen on change attribute
        indicates that the file may have been updated since the cached
        data was obtained, the client without this change being
   immediately reflected on must flush or invalidate the server.  Normally such changes are not
   propagated directly
        cached data for the newly locked region.  A client might choose
        to invalidate all of non-modified cached data that it has for
        the server file but when the only requirement for correct operation is to
        invalidate all of the data in the newly locked region.

   o    Second, before releasing a write lock for a region, all modified
        data is for that region must be flushed to the server, analogous attribute changes are made on the server.  When open delegation is in effect, the  The
        modified attributes
   may data must also be returned written to stable storage.

   Note that flushing data to the server in and the response invalidation of cached
   data must reflect the actual byte ranges locked or unlocked.
   Rounding these up or down to reflect client cache block boundaries
   will cause problems if not carefully done.  For example, writing a CB_RECALL call.

   The result of local caching
   modified block when only half of attributes is that block is within an area being
   unlocked may cause invalid modification to the attribute
   caches maintained on individual clients will not be coherent. Changes
   made in one order on region outside the server
   unlocked area.  This, in turn, may be seen in part of a different order on
   one client and in region locked by
   another client.  Clients can avoid this situation by synchronously
   performing portions of write operations that overlap that portion
   (initial or final) that is not a third order on full block.  Similarly, invalidating
   a different client.

   The typical file system application programming interfaces do locked area which is not
   provide means an integral number of full buffer blocks
   would require the client to atomically modify read one or interrogate attributes for
   multiple files at two partial blocks from the same time.  The following rules provide an
   environment where
   server if the potential incoherences mentioned above can be
   reasonably managed.  These rules are derived from revalidation procedure shows that the practice of
   previous NFS protocols.

   o    All attributes for a given file (per-fsid attributes excepted)
        are cached as a unit at data which the
   client so possesses may not be valid.

   The data that no non-
        serializability can arise within is written to the context of server as a single file.

   o    An upper time boundary is maintained on how long pre-requisite to the
   unlocking of a client cache
        entry can region must be kept without being refreshed from the server.

   o    When operations are performed that change attributes written, at the server, the updated attribute set is requested as part of the
        containing RPC.  This includes directory operations that update
        attributes indirectly.  This is accomplished to stable
   storage.  The client may accomplish this either with synchronous
   writes or by following the
        modifying operation asynchronous writes with a GETATTR operation and then using the
        results of the GETATTR to update the client's cached attributes.

   Note that if the full set of attributes to be cached COMMIT operation.
   This is requested by
   READDIR, required because retransmission of the results can be cached modified data after a
   server reboot might conflict with a lock held by the another client.

   A client on the same basis implementation may choose to accommodate applications which
   use record locking in non-standard ways (e.g. using a record lock as
   attributes obtained via GETATTR.

Draft Specification      NFS version 4 Protocol                July              August 2002

   A client may validate its cached version of attributes for

   a file global semaphore) by
   fetching only the change attribute and assuming that if the change
   attribute has the same value as it did when flushing to the attributes were
   cached, then no attributes have changed.  The possible exception server more data upon an LOCKU
   than is covered by the attribute time_access.

9.7.  Name Caching

   The results of LOOKUP and READDIR operations locked range.  This may be cached to avoid include modified data
   within files other than the cost of subsequent LOOKUP operations.  Just as in one for which the case of
   attribute caching, inconsistencies may arise among unlocks are being done.
   In such cases, the various client
   caches.  To mitigate the effects of these inconsistencies must not interfere with applications whose
   READs and given
   the context of typical file system APIs, WRITEs are being done only within the following rules should
   be followed:

   o    The results bounds of unsuccessful LOOKUPs should not be cached, unless
        they are specifically reverified at record
   locks which the point application holds.  For example, an application locks
   a single byte of use.

   o    An upper time boundary is maintained on how long a file and proceeds to write that single byte.  A
   client name
        cache entry can be kept without verifying that the entry has not
        been made invalid by chose to handle a directory change operation performed LOCKU by
        another client.

   When a client is not making changes flushing all modified data to a directory for which there
   exist name cache entries,
   the client needs to periodically fetch
   attributes for server could validly write that directory single byte in response to ensure an
   unrelated unlock.  However, it would not be valid to write the entire
   block in which that single written byte was located since it includes
   an area that is not being
   modified.  After determining that no modification has occurred, the
   expiration time for the associated name cache entries may be updated
   to locked and might be the current time plus the name cache staleness bound.

   When a client is making changes to a given directory, it needs to
   determine whether there have been changes made to the directory locked by
   other clients.  It does another client.
   Client implementations can avoid this problem by using dividing files with
   modified data into those for which all modifications are done to
   areas covered by an appropriate record lock and those for which there
   are modifications not covered by a record lock.  Any writes done for
   the change attribute as
   reported before former class of files must not include areas not locked and after thus
   not modified on the directory operation client.

9.3.3.  Data Caching and Mandatory File Locking

   Client side data caching needs to respect mandatory file locking when
   it is in the associated
   change_info4 value returned for the operation. effect.  The server presence of mandatory file locking for a given
   file is able to
   communicate to indicated when the client whether the change_info4 data gets back NFS4ERR_LOCKED from a
   READ or WRITE on a file it has an appropriate share reservation for.
   When mandatory locking is provided
   atomically with respect to in effect for a file, the directory operation. client must check
   for an appropriate file lock for data being read or written.  If a
   lock exists for the change
   values are provided atomically, range being read or written, the client is then able to compare
   the pre-operation change value with may
   satisfy the change value in request using the client's
   name validated cache.  If an
   appropriate file lock is not held for the comparison indicates that range of the directory was
   updated read or write,
   the read or write request must not be satisfied by another client, the name client's cache associated with the
   modified directory is purged from the client.  If the comparison
   indicates no modification,
   and the name cache can request must be updated on the
   client sent to reflect the directory operation server for processing.  When a
   read or write request partially overlaps a locked region, the request
   should be subdivided into multiple pieces with each region (locked or
   not) treated appropriately.

9.3.4.  Data Caching and File Identity

   When clients cache data, the associated timeout
   extended.  The post-operation change value file data needs to be saved as organized according
   to the
   basis filesystem object to which the data belongs.  For NFS version
   3 clients, the typical practice has been to assume for future change_info4 comparisons.

   As demonstrated by the scenario above, name purpose of
   caching requires that the distinct filehandles represent distinct filesystem
   objects.  The client revalidate name cache data by inspecting the change attribute
   of a directory at then has the point when choice to organize and maintain the name
   data cache item was cached.
   This requires that the server update on this basis.

   In the change attribute for

Draft Specification NFS version 4 Protocol                July 2002

   directories when protocol, there is now the contents possibility to have
   significant deviations from a "one filehandle per object" model
   because a filehandle may be constructed on the basis of the corresponding directory is
   modified.  For object's
   pathname.  Therefore, clients need a client reliable method to use the change_info4 information
   appropriately and correctly, determine if
   two filehandles designate the server must report the pre and post
   operation change attribute values atomically.  When the server is
   unable same filesystem object.  If clients

Draft Specification      NFS version 4 Protocol              August 2002

   were simply to report the before assume that all distinct filehandles denote distinct
   objects and after values atomically with respect proceed to do data caching on this basis, caching
   inconsistencies would arise between the directory operation, distinct client side objects
   which mapped to the same server must indicate that fact in side object.

   By providing a method to differentiate filehandles, the
   change_info4 return value.  When NFS version 4
   protocol alleviates a potential functional regression in comparison
   with the information is not atomically
   reported, NFS version 3 protocol.  Without this method, caching
   inconsistencies within the same client should could occur and this has not assume
   been present in previous versions of the NFS protocol.  Note that other clients it
   is possible to have such inconsistencies with applications executing
   on multiple clients but that is not
   changed the directory.

9.8.  Directory Caching

   The results of READDIR operations may be used to avoid subsequent
   READDIR operations.  Just as in issue being addressed here.

   For the cases purposes of attribute and name data caching, inconsistencies may arise among the various following steps allow an NFS
   version 4 client caches.
   To mitigate to determine whether two distinct filehandles denote
   the effects same server side object:

   o    If GETATTR directed to two filehandles have different values of these inconsistencies, and given
        the
   context of typical file system APIs, fsid attribute, then the following rules should be
   followed: filehandles represent distinct
        objects.

   o    Cached READDIR information    If GETATTR for a directory which is not obtained any file with an fsid that matches the fsid of
        the two filehandles in question returns a single READDIR operation must always be unique_handles
        attribute with a consistent
        snapshot value of directory contents.  This is determined by using a TRUE, then the two objects are
        distinct.

   o    If GETATTR before directed to the first READDIR and after two filehandles does not return the last
        fileid attribute for one or both of READDIR the handles, then it cannot
        be determined whether the two objects are the same.  Therefore,
        operations which depend on that contributes knowledge (e.g. client side data
        caching) cannot be done reliably.

   o    If GETATTR directed to the cache. two filehandles returns different
        values for the fileid attribute, then they are distinct objects.

   o    An upper time boundary is maintained to indicate    Otherwise they are the length of
        time same object.

9.4.  Open Delegation

   When a directory cache entry file is considered valid before being OPENed, the
        client must revalidate server may delegate further handling
   of opens and closes for that file to the cached information.

   The revalidation technique parallels opening client.  Any such
   delegation is recallable, since the circumstances that discussed in allowed for
   the case of
   name caching.  When delegation are subject to change.  In particular, the client is not changing server may
   receive a conflicting OPEN from another client, the directory in
   question, checking server must
   recall the change attribute of delegation before deciding whether the directory with GETATTR
   is adequate.  The lifetime of OPEN from the cache entry can other
   client may be extended at
   these checkpoints.  When granted.  Making a client delegation is modifying the directory, the
   client needs up to use the change_info4 data to determine whether there
   are other server and
   clients modifying the directory.  If it should not assume that any particular OPEN either will or
   will not result in an open delegation.  The following is determined a typical
   set of conditions that
   no other servers might use in deciding whether OPEN
   should be delegated:

Draft Specification      NFS version 4 Protocol              August 2002

   o    The client modifications are occurring, must be able to respond to the server's callback
        requests.  The server will use the CB_NULL procedure for a test
        of callback ability.

   o    The client may update
   its directory cache must have responded properly to reflect its own changes.

   As demonstrated previously, directory caching requires previous recalls.

   o    There must be no current open conflicting with the requested
        delegation.

   o    There should be no current delegation that conflicts with the
   client revalidate directory cache data by inspecting
        delegation being requested.

   o    The probability of future conflicting open requests should be
        low based on the change
   attribute recent history of a directory at the point when file.

   o    The existence of any server-specific semantics of OPEN/CLOSE
        that would make the directory was cached.
   This requires required handling incompatible with the
        prescribed handling that the server update delegated client would apply (see
        below).

   There are two types of open delegations, read and write.  A read open
   delegation allows a client to handle, on its own, requests to open a
   file for reading that do not deny read access to others.  Multiple
   read open delegations may be outstanding simultaneously and do not
   conflict.  A write open delegation allows the change attribute client to handle, on
   its own, all opens.  Only one write open delegation may exist for
   directories when a
   given file at a given time and it is inconsistent with any read open
   delegations.

   When a client has a read open delegation, it may not make any changes
   to the contents or attributes of the corresponding directory file but it is
   modified.  For assured that no
   other client may do so.  When a client to use has a write open delegation,
   it may modify the change_info4 information
   appropriately and correctly, file data since no other client will be accessing
   the server must report file's data.  The client holding a write delegation may only
   affect file attributes which are intimately connected with the pre and post
   operation change attribute values atomically. file
   data:  size, time_modify, change.

   When a client has an open delegation, it does not send OPENs or
   CLOSEs to the server is
   unable to report but updates the before and after values atomically with respect appropriate status internally.
   For a read open delegation, opens that cannot be handled locally
   (opens for write or that deny read access) must be sent to the directory operation,
   server.

   When an open delegation is made, the server must indicate that fact in response to the
   change_info4 return value.  When OPEN contains an
   open delegation structure which specifies the information is not atomically
   reported, following:

   o    the client should not assume that other clients have not

Draft Specification      NFS version 4 Protocol                July 2002

   changed type of delegation (read or write)

   o    space limitation information to control flushing of data on
        close (write open delegation only, see the directory. section "Open
        Delegation and Data Caching")

Draft Specification      NFS version 4 Protocol                July              August 2002

10.  Minor Versioning

   To address the requirement of

   o    an NFS protocol that can evolve as the
   need arises, the NFS version 4 protocol contains the rules nfsace4 specifying read and
   framework write permissions

   o    a stateid to allow represent the delegation for future minor changes or versioning. READ and WRITE

   The base assumption with respect to minor versioning delegation stateid is that any
   future accepted minor version must follow separate and distinct from the IETF process stateid for
   the OPEN proper.  The standard stateid, unlike the delegation
   stateid, is associated with a particular lock_owner and will continue
   to be
   documented in valid after the delegation is recalled and the file remains
   open.

   When a standards track RFC.  Therefore, each minor version
   number will correspond request internal to an RFC.  Minor version zero of the NFS
   version 4 protocol client is represented by this RFC.  The COMPOUND
   procedure made to open a file and open
   delegation is in effect, it will support be accepted or rejected solely on
   the encoding basis of the minor version following conditions.  Any requirement for other
   checks to be made by the delegate should result in open delegation
   being
   requested denied so that the checks can be made by the client. server itself.

   o    The following items represent the basic rules access and deny bits for the development of
   minor versions.  Note request and the file as
        described in the section "Share Reservations".

   o    The read and write permissions as determined below.

   The nfsace4 passed with delegation can be used to avoid frequent
   ACCESS calls.  The permission check should be as follows:

   o    If the nfsace4 indicates that a future minor version the open may decide to
   modify or add be done, then it
        should be granted without reference to the following rules as part of server.

   o    If the minor version
   definition.

   1    Procedures are not added or deleted

        To maintain nfsace4 indicates that the general RPC model, NFS version 4 minor versions
        will open may not add or delete procedures from be done, then an
        ACCESS request must be sent to the NFS program.

   2    Minor versions may add operations server to obtain the COMPOUND and
        CB_COMPOUND procedures.
        definitive answer.

   The addition of operations to server may return an nfsace4 that is more restrictive than the COMPOUND and CB_COMPOUND
        procedures does not affect
   actual ACL of the RPC model.

   2.1  Minor versions may append attributes to GETATTR4args, bitmap4,
        and GETATTR4res. file.  This allows for the expansion includes an nfsace4 that specifies
   denial of all access.  Note that some common practices such as
   mapping the attribute model traditional user "root" to allow
        for future growth or adaptation.

   2.2  Minor version X must append any new attributes after the last
        documented attribute.

        Since attribute results are specified as an opaque array of
        per-attribute XDR encoded results, user "nobody" may make it
   incorrect to return the complexity actual ACL of adding new
        attributes the file in the midst delegation
   response.

   The use of delegation together with various other forms of caching
   creates the current definitions possibility that no server authentication will ever be too
        burdensome.

   3    Minor versions must not modify the structure of an existing
        operation's arguments or results.

Draft Specification      NFS version 4 Protocol                July 2002

        Again the complexity of handling multiple structure definitions
   performed for a single operation is too burdensome.  New operations should
        be added instead given user since all of modifying existing structures for a minor
        version.

        This rule does not preclude the following adaptations in a minor
        version.

        o    adding bits to flag fields such as new attributes to
             GETATTR's bitmap4 data type

        o    adding bits to existing attributes like ACLs that have flag
             words

        o    extending enumerated types (including NFS4ERR_*) with new
             values

   4    Minor versions may not modify the structure of existing
        attributes.

   5    Minor versions may not delete operations.

        This prevents user's requests might be
   satisfied locally.  Where the potential reuse of a particular operation
        "slot" in a future minor version.

   6    Minor versions may not delete attributes.

   7    Minor versions may not delete flag bits or enumeration values.

   8    Minor versions may declare an operation as mandatory to NOT
        implement.

        Specifying an operation as "mandatory to not implement" client is
        equivalent to obsoleting an operation.  For depending on the client, it means
        that server for
   authentication, the operation client should not be sent to the server.  For the
        server, an NFS error can be returned as opposed to "dropping" sure authentication occurs for
   each user by use of the request as an XDR decode error. ACCESS operation.  This approach allows for should be the obsolescence of case
   even if an ACCESS operation while maintaining its structure
        so that a future minor version can reintroduce would not be required otherwise.  As
   mentioned before, the operation.

   8.1  Minor versions may declare attributes mandatory to NOT
        implement.

   8.2  Minor versions server may declare flag bits or enumeration values as
        mandatory to NOT implement. enforce frequent authentication by
   returning an nfsace4 denying all access with every open delegation.

Draft Specification      NFS version 4 Protocol                July              August 2002

   9    Minor versions may downgrade features from mandatory to
        recommended, or recommended to optional.

   10   Minor versions may upgrade features from optional to recommended
        or recommended to mandatory.

   11   A client

9.4.1.  Open Delegation and server that support minor version X must support
        minor versions 0 (zero) through X-1 as well.

   12   No new features may be introduced as mandatory in a minor
        version.

        This rule Data Caching

   OPEN delegation allows for the introduction of new functionality and
        forces the use much of implementation experience before designating a
        feature as mandatory.

   13   A client MUST NOT attempt to use a stateid, file handle, or
        similar returned object from the COMPOUND procedure with minor
        version X for another COMPOUND procedure message overhead associated with minor version Y,
        where X != Y.

Draft Specification      NFS version 4 Protocol                July 2002

11.  Internationalization

   The primary issue in which NFS needs
   the opening and closing files to deal with
   internationalization, or I18N, be eliminated.  An open when an open
   delegation is with respect in effect does not require that a validation message be
   sent to file names and
   other strings as used within the protocol.  The choice of string
   representation must allow reasonable name/string access to clients
   which use various languages. server.  The UTF-8 encoding continued endurance of the UCS as
   defined by [ISO10646] allows "read open
   delegation" provides a guarantee that no OPEN for this type of access write and follows the
   policy described in "IETF Policy on Character Sets thus no
   write has occurred.  Similarly, when closing a file opened for write
   and Languages",
   [RFC2277].  This choice if write open delegation is explained further in effect, the following.

11.1.  Universal Versus Local Character Sets

   [RFC1345] describes a table of 16 bit characters for many different
   languages (the bit encodings match Unicode, though of course RFC1345 data written does not
   have to be flushed to the server until the open delegation is somewhat out
   recalled.  The continued endurance of date with respect to current Unicode assignments).
   Each character from each language has the open delegation provides a unique 16 bit value in
   guarantee that no open and thus no read or write has been done by
   another client.

   For the 16
   bit character set.  Thus this table can be thought purposes of open delegation, READs and WRITEs done without an
   OPEN are treated as a universal
   character set.  [RFC1345] then talks about groupings the functional equivalents of subsets a corresponding
   type of OPEN.  This refers to the entire 16 bit character set into "Charset Tables".  For example
   one might take all READs and WRITEs that use the Greek characters from
   special stateids consisting of all zero bits or all one bits.
   Therefore, READs or WRITEs with a special stateid done by another
   client will force the 16 bit table (which
   are consecutively allocated), and normalize their offsets server to recall a table
   that fits in 7 bits.  Thus it is determined that "lower case alpha" write open delegation.  A
   WRITE with a special stateid done by another client will force a
   recall of read open delegations.

   With delegations, a client is in able to avoid writing data to the same position as "upper case a" in
   server when the US-ASCII table, and
   "upper case alpha" CLOSE of a file is serviced.  The file close system
   call is in the same position as "lower case a" in usual point at which the
   US-ASCII table.

   These normalized subset character sets can be thought client is notified of as "local
   character sets", suitable for an operating system locale.

   Local character sets are not suitable a lack of
   stable storage for the NFS protocol.  Consider
   someone who creates a modified file with a name in a Swedish character set.
   If someone else later goes to access data generated by the
   application.  At the close, file with their locale set data is written to the Swedish language, then there are no problems.  But if someone
   in say server and
   through normal accounting the US-ASCII locale goes server is able to access the file, the file name
   will look very different, because determine if the Swedish characters in
   available filesystem space for the 7 bit
   table will now data has been exceeded (i.e.
   server returns NFS4ERR_NOSPC or NFS4ERR_DQUOT).  This accounting
   includes quotas.  The introduction of delegations requires that a
   alternative method be represented in US-ASCII characters on place for the display.
   It would be preferable same type of communication to give
   occur between client and server.

   In the US-ASCII user a way to display delegation response, the
   file name using Swedish glyphs. In order to do that, server provides either the NFS protocol
   would have to include limit of
   the locale with size of the file name on each operation
   to create a file.

   But then what or the number of modified blocks and associated
   block size.  The server must ensure that the situation when there is a path name on client will be able to
   flush data to the server like:

           /component-1/component-2/component-3

   Each component could have been created with of a different locale.  If
   one issues CREATE with multi-component path name, size equal to that provided in the
   original delegation.  The server must make this assurance for all
   outstanding delegations.  Therefore, the server must be careful in
   its management of available space for new or modified data taking
   into account available filesystem space and if some any applicable quotas.
   The server can recall delegations as a result of managing the
   leading components already exist, what is to be done with
   available filesystem space.  The client should abide by the
   existing components?  Is server's
   state space limits for delegations.  If the current locale attribute replaced client exceeds the stated
   limits for the delegation, the server's behavior is undefined.

   Based on server conditions, quotas or available filesystem space, the
   server may grant write open delegations with very restrictive space
   limitations.  The limitations may be defined in a way that will
   always force modified data to be flushed to the user's current one?  These types of situations quickly become too server on close.

Draft Specification      NFS version 4 Protocol                July              August 2002

   complex when there is an alternate solution.

   If

   With respect to authentication, flushing modified data to the NFS version 4 protocol used server
   after a universal 16 bit or 32 bit
   character set (or an encoding CLOSE has occurred may be problematic.  For example, the user
   of a 16 bit or 32 bit character set
   into octets), then the server application may have logged off the client and unexpired
   authentication credentials may not be present.  In this case, the
   client may need not to take special care if to ensure that local unexpired
   credentials will in fact be available.  This may be accomplished by
   tracking the locale expiration time of the user accessing the file is different than the locale credentials and flushing data well in
   advance of the
   user who created the file.  The unique 16 bit their expiration or 32 bit encoding by making private copies of
   the character allows
   credentials to assure their availability when needed.

9.4.2.  Open Delegation and File Locks

   When a client holds a write open delegation, lock operations are
   performed locally.  This includes those required for determination mandatory file
   locking.  This can be done since the delegation implies that there
   can be no conflicting locks.  Similarly, all of what language the character
   is from and also how to display revalidations
   that character on would normally be associated with obtaining locks and the client.  The
   server
   flushing of data associated with the releasing of locks need not know what locales be
   done.

   When a client holds a read open delegation, lock operations are used.

11.2.  Overview not
   performed locally.  All lock operations, including those requesting
   non-exclusive locks, are sent to the server for resolution.

9.4.3.  Handling of Universal Character Set Standards CB_GETATTR

   The previous section makes a case server needs to employ special handling for using a universal character
   set.  This section makes GETATTR where the case
   target is a file that has a write open delegation in effect.  The
   reason for using UTF-8 as this is that the specific
   universal character set for client holding the NFS version 4 protocol.

   [RFC2279] discusses UTF-* (UTF-8 and other UTF-XXX encodings),
   Unicode, and UCS-*.  There are two standards bodies managing
   universal code sets:

   o    ISO/IEC which has write delegation may
   have modified the standard 10646-1

   o    Unicode which has data and the Unicode standard

   Both standards bodies have pledged server needs to track each other's assignments
   of character codes. reflect this change to
   the second client that submitted the GETATTR.  Therefore, the client
   holding the write delegation needs to be interrogated.  The following server
   will use the CB_GETATTR operation.  The only attributes that the
   server can reliably query via CB_GETATTR are size and change.

   Since CB_GETATTR is being used to satisfy another client's GETATTR
   request, the server only needs to know if the client holding the
   delegation has a brief analysis modified version of the various standards.

   UCS       Universal Character Set.  This is ISO/IEC 10646-1: "a
             multi-octet character set called file.  If the Universal Character
             Set (UCS), which encompasses most client's copy
   of the world's writing
             systems."

   UCS-2     a two octet per character encoding that addresses delegated file is not modified (data or size), the first
             2^16 characters of UCS. Currently there are no UCS
             characters beyond server can
   satisfy the second client's GETATTR request from the attributes
   stored locally at the server.  If the file is modified, the server
   only needs to know about this modified state.  If the server
   determines that range.

   UCS-4     a four octet per character encoding the file is currently modified, it will respond to
   the second client's GETATTR as if the file had been modified locally
   at the server.  This means that permits the
             encoding of up server will take the current time
   and apply it to 2^31 characters.

   UTF       UTF is an abbreviation the construction of attributes like change and
   time_modify.

   Since the term "UCS transformation
             format" form of the change attribute is determined by the server
   and is used in opaque to the naming of various standards for
             encoding of UCS characters as described below.

   UTF-1     Only historical interest; it has been removed from 10646-1 client, the client and server need to agree on a

Draft Specification      NFS version 4 Protocol                July              August 2002

   UTF-7     Encodes

   method of communicating the entire "repertoire" modified state of UCS "characters using
             only octets with the higher order bit clear".  [RFC2152]
             describes UTF-7. UTF-7 accomplishes this by reserving one file.  For the size
   attribute, the client will report its current view of the 7bit US-ASCII characters as file size.
   For the change attribute, the handling is more involved.

   For the client, the following steps will be taken when receiving a "shift" character to
             indicate non-US-ASCII characters.

   UTF-8     Unlike UTF-7, uses all 8 bits
   write delegation:

   o    The value of the octets. US-ASCII
             characters are encoded as before unchanged. Any octet with change attribute will be obtained from the high bit cleared can only mean a US-ASCII character.
        server and cached.  Let this value be represented by c.

   o    The high bit set means that client will create a UCS character value greater than c that will be used
        for communicating modified data is being
             encoded.

   UTF-16    Encodes UCS-4 characters into UCS-2 characters using a
             reserved range in UCS-2.

   Unicode   Unicode and UCS-2 are held at the same; [RFC2279] states:

        Up to client.  Let this
        value be represented by d.

   o    When the present time, changes in Unicode and amendments
        to ISO/IEC 10646 have tracked each other, so that client is queried via CB_GETATTR for the
        character repertoires and code point assignments have
        remained in sync.  The relevant standardization committees
        have committed change
        attribute, it checks to maintain this very useful synchronism.

11.3.  Difficulties with UCS-4, UCS-2, Unicode

   Adapting existing applications, and see if it holds modified data.  If the
        file systems is modified, the value d is returned for the change
        attribute value.  If this file is not currently modified, the
        client returns the value c for the change attribute.

   While the change attribute is opaque to multi-octet
   schemes like UCS and Unicode can be difficult.  A significant amount
   of code client in the sense that it
   has been written to process streams no idea what units of bytes. Also there are
   many existing stored objects described with 7 bit or 8 bit
   characters. Doubling or quadrupling time, if any, the bandwidth and storage
   requirements seems like an expensive way server is counting change
   with, it is not opaque in that the client has to accomplish I18N.

   UCS-2 treat it as an
   integer, and Unicode are "only" 16 bits long.  That might seem the server has to be
   enough but, according able to [Unicode1], 49,194 Unicode characters are
   already assigned.  According see the results of the
   client's changes to [Unicode2] there are still more
   languages that need integer. Therefore, the server MUST encode
   the change attribute in network order when sending it to the client,
   the client MUST decode it from network order to be added.

11.4.  UTF-8 and its solutions

   UTF-8 solves problems for NFS that exist with native order when
   receiving it, and the use client MUST encode it network order when
   sending it to the server. For this reason, change is defined as an
   integer, rather than an opaque array of UCS and
   Unicode.  UTF-8 octets.

   For the server, the following steps will encode 16 bit and 32 bit characters in be taken when providing a way
   that
   write delegation:

   o    On providing a write delegation, the server will cache a copy of
        the change attribute.  Let this value be compact represented by sc.

   o    The server obtains the change attribute from the client.  Let
        this value be cc.

   o    If the value cc is equal to sc, the file is not modified and the
        server returns the current values for change and time_modify
        (for example) to the client requesting GETATTR.

   o    If the value cc is NOT equal to sc, the file is currently
        modified at the client and most users. likely will be modified at the
        server at a future time.  The encoding table from UCS-4 server then uses the current time
        to
   UTF-8, as copied from [RFC2279]:

      UCS-4 range (hex.)           UTF-8 octet sequence (binary)
    0000 0000-0000 007F   0xxxxxxx
    0000 0080-0000 07FF   110xxxxx 10xxxxxx
    0000 0800-0000 FFFF   1110xxxx 10xxxxxx 10xxxxxx construct attributes values for change and time_modify and
        returns those values to the requestor.

   o    In the case that the file attribute size is different than the

Draft Specification      NFS version 4 Protocol                July              August 2002

    0001 0000-001F FFFF   11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
    0020 0000-03FF FFFF   111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
    0400 0000-7FFF FFFF   1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
   10xxxxxx

   See [RFC2279] for precise encoding and decoding rules. Note because

        server's current value, the server treats this as a modification
        regardless of UTF-16, the algorithm from Unicode/UCS-2 to UTF-8 needs value of the change attribute retrieved via
        CB_GETATTR and responds to account
   for the reserved range second client as in the last
        step.

   This methodology resolves issues of clock differences between D800 client
   and DFFF.

   Note that server and other scenarios where the 16 bit UCS or Unicode characters require no more than 3
   octets to encode into UTF-8

   Interestingly, UTF-8 has room to handle characters larger than 31
   bits, because the leading octet of form:

           1111111x

   is not defined. If needed, ISO could either use that octet to
   indicate a sequence of an encoded 8 octet character, or perhaps use
   11111110 to permit the next octet to indicate an even more expandable
   character set.

   So using UTF-8 to represent character encodings means never having to
   run out CB_GETATTR break
   down.

9.4.4.  Recall of room.

11.5.  Normalization Open Delegation

   The client and server operating environments may differ in their
   policies and operational methods following events necessitate recall of an open delegation:

   o    Potentially conflicting OPEN request (or READ/WRITE done with respect to character
   normalization (See [Unicode1]
        "special" stateid)

   o    SETATTR issued by another client

   o    REMOVE request for the file

   o    RENAME request for the file as either source or target of the
        RENAME

   Whether a discussion RENAME of normalization
   forms).  This difference may also exist between applications on a directory in the
   same client.  This adds path leading to the difficulty file
   results in recall of providing a single
   normalization policy for an open delegation depends on the protocol semantics of
   the server filesystem.  If that allows for maximal
   interoperability.  This issue filesystem denies such RENAMEs when a
   file is similar open, the recall must be performed to determine whether the
   file in question is, in fact, open.

   In addition to the character case issues
   where situations above, the server may or may not support case insensitive file name
   matching and may or may not preserve the character case when storing
   file names.  The protocol does not mandate a particular behavior but
   allows choose to recall
   open delegations at any time if resource constraints make it
   advisable to do so.  Clients should always be prepared for the various permutations.

   The NFS version 4 protocol does not mandate the use
   possibility of recall.

   When a particular
   normalization form at this time.  A later revision of this
   specification may specify client receives a particular normalization form.
   Therefore, recall for an open delegation, it needs to
   update state on the server and before returning the delegation.  These
   same updates must be done whenever a client can expect that they may receive
   unnormalized characters within protocol requests chooses to return a
   delegation voluntarily.  The following items of state need to be
   dealt with:

   o    If the file associated with the delegation is no longer open and responses.
        no previous CLOSE operation has been sent to the server, a CLOSE
        operation must be sent to the server.

   o    If a file has other open references at the operating environment requires normalization, client, then the
   implementation OPEN
        operations must normalize be sent to the various UTF-8 encoded strings
   within server.  The appropriate stateids
        will be provided by the protocol before presenting server for subsequent use by the information to an
   application (at client
        since the client) or local file system (at delegation stateid will not longer be valid.  These
        OPEN requests are done with the claim type of
        CLAIM_DELEGATE_CUR.  This will allow the presentation of the server).

Draft Specification      NFS version 4 Protocol                July              August 2002

12.  Error Definitions

   NFS error numbers are assigned to failed operations within a compound
   request.  A compound request contains a number of NFS operations

        delegation stateid so that
   have their results encoded in sequence in a compound reply.  The
   results of successful operations will consist of an NFS4_OK status
   followed by the encoded results of client can establish the operation.
        appropriate rights to perform the OPEN.  (see the section
        "Operation 18: OPEN" for details.)

   o    If an NFS
   operation fails, an error status will there are granted file locks, the corresponding LOCK
        operations need to be entered in performed.  This applies to the reply and write open
        delegation case only.

   o    For a write open delegation, if at the
   compound request will be terminated.

   A description time of each defined error follows:

   NFS4_OK               Indicates recall the operation completed successfully.

   NFS4ERR_ACCESS        Permission denied. The caller does file
        is not have the
                         correct permission to perform open for write, all modified data for the requested
                         operation. Contrast this with NFS4ERR_PERM,
                         which restricts itself file must be
        flushed to owner or privileged
                         user permission failures.

   NFS4ERR_ATTRNOTSUPP   An attribute specified is not supported by the server.  Does  If the delegation had not apply to existed, the GETATTR
        client would have done this data flush before the CLOSE
        operation.

   NFS4ERR_BADHANDLE     Illegal NFS

   o    For a write open delegation when a file handle. The is still open at the
        time of recall, any modified data for the file handle failed
                         internal consistency checks.

   NFS4ERR_BADOWNER      An owner, owner_group, or ACL attribute value
                         can not be translated needs to local representation.

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

   NFS4ERR_BAD_COOKIE    READDIR cookie is stale.

   NFS4ERR_BAD_SEQID     The sequence number

   o    With the write open delegation in a locking request place, it is
                         neither the next expected number or the last
                         number processed.

   NFS4ERR_BAD_STATEID   A stateid generated by the current server
                         instance, but which does not designate any
                         locking state (either current or superseded)
                         for a current lockowner-file pair, was used.

   NFS4ERR_BADXDR        The server encountered an XDR decoding error
                         while processing an operation.

   NFS4ERR_CLID_INUSE    The SETCLIENTID procedure has found possible that a
                         client id is already in use by another client.

Draft Specification      NFS version 4 Protocol                July 2002

   NFS4ERR_DELAY         The server initiated the request, but
        file was not
                         able to complete it in a timely fashion. The
                         client should wait and then try truncated during the request
                         with a new RPC transaction ID. duration of the delegation.  For
        example,
                         this error should be returned from the truncation could have occurred as a server
                         that supports hierarchical storage and receives result of an
        OPEN UNCHECKED with a request to process size attribute value of zero.  Therefore,
        if a truncation of the file that has been
                         migrated. In occurred and this case, operation has
        not been propagated to the server should start server, the immigration process and respond to client
                         with this error.  This error may also truncation must occur
                         when a necessary delegation recall makes
                         processing a request in a timely fashion
                         impossible.

   NFS4ERR_DENIED        An attempt
        before any modified data is written to lock a the server.

   In the case of write open delegation, file is denied.  Since
                         this may be a temporary condition, locking imposes some
   additional requirements.  To precisely maintain the client associated
   invariant, it is encouraged required to retry the flush any modified data in any region
   for which a write lock request until was released while the lock is accepted.

   NFS4ERR_DQUOT         Resource (quota) hard limit exceeded. The
                         user's resource limit on write delegation was in
   effect.  However, because the write open delegation implies no other
   locking by other clients, a simpler implementation is to flush all
   modified data for the server has been
                         exceeded.

   NFS4ERR_EXIST         File exists. The file specified already exists.

   NFS4ERR_EXPIRED       A lease (as described just above) if any write
   lock has expired that is being used in been released while the
                         current procedure.

   NFS4ERR_FBIG          File too large. The operation would have caused write open delegation was in effect.

   An implementation need not wait until delegation recall (or deciding
   to voluntarily return a file delegation) to grow beyond perform any of the above
   actions, if implementation considerations (e.g. resource availability
   constraints) make that desirable.  Generally, however, the fact that
   the actual open state of the server's limit.

   NFS4ERR_FHEXPIRED     The file handle provided is volatile may continue to change makes it not
   worthwhile to send information about opens and has
                         expired at closes to the server.

   NFS4ERR_GRACE         The server is server,
   except as part of delegation return.  Only in its recovery or grace period
                         which should match the lease period case of closing the
                         server.

   NFS4ERR_INVAL         Invalid argument or unsupported argument for an
                         operation. Two examples are attempting a
                         READLINK on an object other than a symbolic
                         link or attempting
   open that resulted in obtaining the delegation would clients be
   likely to SETATTR a time field on a
                         server do this early, since, in that does case, the close once done
   will not support this operation.

   NFS4ERR_IO            I/O error. A hard error (for example, a disk
                         error) occurred while processing be undone.  Regardless of the requested
                         operation.

   NFS4ERR_ISDIR         Is a directory. The caller specified a
                         directory in a non-directory operation.

   NFS4ERR_LEASE_MOVED   A lease being renewed client's choices on scheduling
   these actions, all must be performed before the delegation is associated with a file
   returned, including (when applicable) the close that corresponds to
   the open that resulted in the delegation.  These actions can be
   performed either in previous requests or in previous operations in
   the same COMPOUND request.

Draft Specification      NFS version 4 Protocol                July              August 2002

                         system that has been migrated to

9.4.5.  Delegation Revocation

   At the point a new server.

   NFS4ERR_LOCKED        A read or write operation was attempted delegation is revoked, if there are associated opens
   on the client, the applications holding these opens need to be
   notified.  This notification usually occurs by returning errors for
   READ/WRITE operations or when a
                         locked close is attempted for the open file.

   NFS4ERR_LOCK_RANGE    A lock request

   If no opens exist for the file at the point the delegation is operating on a sub-range
   revoked, then notification of a
                         current lock the revocation is unnecessary.
   However, if there is modified data present at the client for the lock owner and
   file, the server
                         does not support this type user of request.

   NFS4ERR_MINOR_VERS_MISMATCH
                         The server has received a request that
                         specifies an unsupported minor version.  The
                         server must return a COMPOUND4res with a zero
                         length operations result array.

   NFS4ERR_MLINK         Too many hard links.

   NFS4ERR_MOVED         The filesystem which contains the current
                         filehandle object has been relocated or
                         migrated application should be notified.  Unfortunately,
   it may not be possible to another server.  The client notify the user since active applications
   may
                         obtain not be present at the new filesystem location by obtaining client.  See the "fs_locations" attribute section "Revocation
   Recovery for Write Open Delegation" for additional details.

9.5.  Data Caching and Revocation

   When locks and delegations are revoked, the current
                         filehandle. assumptions upon which
   successful caching depend are no longer guaranteed.  For further discussion, refer to
                         the section "Filesystem Migration or
                         Relocation".

   NFS4ERR_NAMETOOLONG   The filename in an operation was too long.

   NFS4ERR_NODEV         No such device.

   NFS4ERR_NOENT         No such file or directory. The file any locks or
                         directory name specified does not exist.

   NFS4ERR_NOFILEHANDLE  The logical current file handle value has not
   share reservations that have been set properly.  This may revoked, the corresponding owner
   needs to be notified.  This notification includes applications with a result of a
                         malformed COMPOUND operation (i.e. no PUTFH or
                         PUTROOTFH before an operation that requires the
                         current
   file handle be set).

   NFS4ERR_NO_GRACE      A reclaim of client state open that has fallen outside of
                         the grace period of the server.  As a result,
                         the server can not guarantee that conflicting
                         state corresponding delegation which has not been provided to another client.

   NFS4ERR_NOSPC         No space left on device. The operation would
                         have caused the server's file system to exceed
                         its limit.

   NFS4ERR_NOTDIR        Not a directory. The caller specified a non-
                         directory in a directory operation.

   NFS4ERR_NOTEMPTY      An attempt was made to remove a directory that

Draft Specification      NFS version 4 Protocol                July 2002

                         was not empty.

   NFS4ERR_NOTSUPP       Operation is not supported.

   NFS4ERR_NOT_SAME      This error is returned by revoked.
   Cached data associated with the VERIFY operation
                         to signify that revocation must be removed from the attributes compared were
                         not
   client.  In the same as provided case of modified data existing in the client's
                         request.

   NFS4ERR_NXIO          I/O error. No such device or address.

   NFS4ERR_OLD_STATEID   A stateid which designates cache,
   that data must be removed from the locking state
                         for a lockowner-file at an earlier time was
                         used.

   NFS4ERR_OPENMODE      The client attempted a READ, WRITE, or SETATTR
                         operation not sanctioned without it being written to
   the server.  As mentioned, the assumptions made by the stateid passed
                         (e.g. writing to a file opened only for read).

   NFS4ERR_PERM          Not owner. The operation was not allowed
                         because client are no
   longer valid at the caller is either not point when a privileged
                         user (root) lock or not delegation has been revoked.
   For example, another client may have been granted a conflicting lock
   after the owner revocation of the target of lock at the operation.

   NFS4ERR_READDIR_NOSPC The encoded response to a READDIR request
                         exceeds first client.  Therefore, the size limit set by
   data within the initial
                         request.

   NFS4ERR_RECLAIM_BAD   The reclaim provided lock range may have been modified by the client does not
                         match any of other
   client.  Obviously, the server's state consistency
                         checks and first client is bad.

   NFS4ERR_RECLAIM_CONFLICT
                         The reclaim provided by unable to guarantee to the client
   application what has
                         encountered a conflict and can not be provided.
                         Potentially indicates a misbehaving client.

   NFS4ERR_RESOURCE      For the processing of the COMPOUND procedure, occurred to the server may exhaust available resources and
                         can not continue processing procedures within file in the COMPOUND operation.  This error case of revocation.

   Notification to a lock owner will be
                         returned from the server in those instances many cases consist of
                         resource exhaustion related to simply
   returning an error on the processing
                         of next and all subsequent READs/WRITEs to the COMPOUND procedure.

   NFS4ERR_ROFS          Read-only
   open file system. A modifying operation
                         was attempted or on a read-only file system.

   NFS4ERR_SAME          This error is returned by the NVERIFY operation
                         to signify that the attributes compared were close.  Where the same methods available to a client
   make such notification impossible because errors for certain
   operations may not be returned, more drastic action such as provided signals
   or process termination may be appropriate.  The justification for
   this is that an invariant for which an application depends on may be
   violated.  Depending on how errors are typically treated for the
   client operating environment, further levels of notification
   including logging, console messages, and GUI pop-ups may be
   appropriate.

9.5.1.  Revocation Recovery for Write Open Delegation

   Revocation recovery for a write open delegation poses the special
   issue of modified data in the client's request. client cache while the file is not
   open.  In this situation, any client which does not flush modified

Draft Specification      NFS version 4 Protocol                July              August 2002

   NFS4ERR_SERVERFAULT   An error occurred on

   data to the server on each close must ensure that the user receives
   appropriate notification of the failure as a result of the
   revocation.  Since such situations may require human action to
   correct problems, notification schemes in which does the appropriate user
   or administrator is notified may be necessary.  Logging and console
   messages are typical examples.

   If there is modified data on the client, it must not
                         map be flushed
   normally to any of the legal NFS version 4 protocol
                         error values.  The server.  A client should translate this
                         into an appropriate error.  UNIX clients may
                         choose to translate this to EIO.

   NFS4ERR_SHARE_DENIED  An attempt to OPEN a file with provide a share
                         reservation has failed because copy of a share
                         conflict.

   NFS4ERR_STALE         Invalid file handle. The
   the file handle given data as modified during the delegation under a different
   name in the arguments was invalid. The file referred filesystem name space to
                         by ease recovery.  Note that when
   the client can determine that the file handle no longer exists or access
                         to it has been revoked.

   NFS4ERR_STALE_CLIENTID A clientid not recognized been modified by any
   other client, or when the server was
                          used client has a complete cached copy of file
   in question, such a locking or SETCLIENTID_CONFIRM
                          request.

   NFS4ERR_STALE_STATEID A stateid generated by an earlier server
                         instance was used.

   NFS4ERR_SYMLINK       The current saved copy of the client's view of the file handle provided may
   be of particular value for recovery.  In other case, recovery using a LOOKUP
                         is not a directory
   copy of the file based partially on the client's cached data and
   partially on the server copy as modified by other clients, will be
   anything but a symbolic link.  Also
                         used if straightforward, so clients may avoid saving file
   contents in these situations or mark the final component results specially to warn
   users of possible problems.

   Saving of such modified data in delegation revocation situations may
   be limited to files of the OPEN path is a symbolic link.

   NFS4ERR_TOOSMALL      Buffer certain size or request is too small.

   NFS4ERR_WRONGSEC      The security mechanism being might be used by only when
   sufficient disk space is available within the target filesystem.
   Such saving may also be restricted to situations when the client
                         for has
   sufficient buffering resources to keep the procedure does not match cached copy available
   until it is properly stored to the server's
                         security policy. target filesystem.

9.6.  Attribute Caching

   The client should change the
                         security mechanism being used attributes discussed in this section do not include named
   attributes.  Individual named attributes are analogous to files and retry
   caching of the
                         operation.

   NFS4ERR_XDEV          Attempt data for these needs to do a cross-device hard link.

Draft Specification      NFS version 4 Protocol                July 2002

13.  NFS Version 4 Requests

   For the NFS version 4 RPC program, there be handled just as data
   caching is for ordinary files.  Similarly, LOOKUP results from an
   OPENATTR directory are two traditional RPC
   procedures: NULL and COMPOUND.  All to be cached on the same basis as any other functionality
   pathnames and similarly for directory contents.

   Clients may cache file attributes obtained from the server and use
   them to avoid subsequent GETATTR requests.  Such caching is defined as
   a set write
   through in that modification to file attributes is always done by
   means of operations requests to the server and these operations are defined in normal
   XDR/RPC syntax should not be done locally and semantics.  However, these operations
   cached.  The exception to this are
   encapsulated within the COMPOUND procedure.  This requires modifications to attributes that
   are intimately connected with data caching.  Therefore, extending a
   file by writing data to the local data cache is reflected immediately
   in the size as seen on the client combine one or more of without this change being
   immediately reflected on the NFS version 4 operations into a
   single request.

   The NFS4_CALLBACK program is used server.  Normally such changes are not
   propagated directly to provide the server but when the modified data is
   flushed to client
   signaling and the server, analogous attribute changes are made on the
   server.  When open delegation is constructed in a similar fashion as effect, the modified attributes
   may be returned to the server in the response to a CB_RECALL call.

Draft Specification      NFS version 4 program. Protocol              August 2002

   The procedures CB_NULL and CB_COMPOUND are defined result of local caching of attributes is that the attribute
   caches maintained on individual clients will not be coherent. Changes
   made in one order on the
   same way as NULL server may be seen in a different order on
   one client and COMPOUND are within in a third order on a different client.

   The typical filesystem application programming interfaces do not
   provide means to atomically modify or interrogate attributes for
   multiple files at the NFS program. same time.  The
   CB_COMPOUND request also encapsulates following rules provide an
   environment where the remaining operations of potential incoherences mentioned above can be
   reasonably managed.  These rules are derived from the
   NFS4_CALLBACK program.  There is no predefined RPC program number practice of
   previous NFS protocols.

   o    All attributes for
   the NFS4_CALLBACK program.  It is up to a given file (per-fsid attributes excepted)
        are cached as a unit at the client to specify a
   program number in so that no non-
        serializability can arise within the "transient" program range.  The program and
   port number context of a single file.

   o    An upper time boundary is maintained on how long a client cache
        entry can be kept without being refreshed from the NFS4_CALLBACK program server.

   o    When operations are provided by performed that change attributes at the client
        server, the updated attribute set is requested as part of the SETCLIENTID
        containing RPC.  This includes directory operations that update
        attributes indirectly.  This is accomplished by following the
        modifying operation with a GETATTR operation and therefore is fixed for then using the
   life
        results of the client instantiation.

13.1.  Compound Procedure

   The COMPOUND procedure provides GETATTR to update the opportunity for better
   performance within high latency networks.  The client can avoid
   cumulative latency client's cached attributes.

   Note that if the full set of multiple RPCs attributes to be cached is requested by combining multiple dependent
   operations into a single COMPOUND procedure.
   READDIR, the results can be cached by the client on the same basis as
   attributes obtained via GETATTR.

   A compound operation client may provide validate its cached version of attributes for protocol simplification a file by allowing
   fetching just both the client to
   combine basic procedures into a single request change and time_access attributes and assuming
   that is customized for if the client's environment.

   The CB_COMPOUND procedure precisely parallels change attribute has the features of
   COMPOUND same value as described above.

   The basic structure of the COMPOUND procedure is:

   +-----+--------------+--------+-----------+-----------+-----------+--
   | tag | minorversion | numops | op + args | op + args | op + args |
   +-----+--------------+--------+-----------+-----------+-----------+--

   and it did when the reply's structure is:

          +------------+-----+--------+-----------------------+--
          |last status | tag | numres | status + op + results |
          +------------+-----+--------+-----------------------+--
   attributes were cached, then no attributes other than time_access
   have changed.  The numops and numres fields, used reason why time_access is also fetched is because
   many servers operate in environments where the depiction above, represent operation that updates
   change does not update time_access.  For example, POSIX file
   semantics do not update access time when a file is modified by the count
   write system call.  Therefore, the client that wants a current
   time_access value should fetch it with change during the attribute
   cache validation processing and update its cached time_access.

   The client may maintain a cache of modified attributes for those
   attributes intimately connected with data of modified regular files
   (size, time_modify, and change). Other than those three attributes,
   the counted array encoding use client MUST NOT maintain a cache of modified attributes. Instead,
   attribute changes are immediately sent to signify the number server.

   In some operating environments, the equivalent to time_access is
   expected to be implicitly updated by each read of
   arguments or results encoded in the request and response.  As per content of the
   XDR encoding, these counts must match exactly
   file object.  If an NFS client is caching the number content of operation a file
   object, whether it is a regular file, directory, or symbolic link,

Draft Specification      NFS version 4 Protocol                July              August 2002

   arguments

   the client SHOULD NOT update the time_access attribute (via SETATTR
   or results encoded.

13.2.  Evaluation of a Compound Request

   The server will process small READ or READDIR request) on the COMPOUND procedure by evaluating server with each of
   the operations within read that
   is satisfied from cache.  The reason is that this can defeat the COMPOUND procedure in order.  Each
   component operation consists
   performance benefits of a 32 bit operation code, followed by
   the argument caching content, especially since an explicit
   SETATTR of length determined by time_access may alter the type of operation. The
   results of each operation are encoded in sequence into a reply
   buffer.  The results of each operation are preceded by change attribute on the opcode and
   a status code (normally zero). server.
   If an operation results in a non-zero
   status code, the status will be encoded and evaluation of change attribute changes, clients that are caching the
   compound sequence content
   will halt and think the reply content has changed, and will be returned.  Note
   that evaluation stops even in re-read unmodified data
   from the event server.  Nor is the client encouraged to maintain a modified
   version of "non error" conditions
   such as NFS4ERR_SAME.

   There are no atomicity requirements for time_access in its cache, since this would mean that the operations contained
   within
   client will either eventually have to write the COMPOUND procedure.  The operations being evaluated as
   part of a COMPOUND request may be evaluated simultaneously with other
   COMPOUND requests that access time to the
   server receives.

   It is with bad performance effects, or it would never update the client's responsibility for recovering from any partially
   completed COMPOUND procedure.  Partially completed COMPOUND
   procedures may occur at any point due to errors such as
   NFS4ERR_RESOURCE and NFS4ERR_DELAY.  This may occur even given
   server's time_access, thereby resulting in a situation where an
   otherwise valid operation string.  Further,
   application that caches access time between a server reboot which
   occurs in close and open of the middle
   same file observes the access time oscillating between the past and
   present.  The time_access attribute always means the time of processing last
   access to a COMPOUND procedure file by a read that was satisfied by the server. This way
   clients will tend to see only time_access changes that go forward in
   time.

9.7.  Name Caching

   The results of LOOKUP and READDIR operations may leave be cached to avoid
   the
   client with cost of subsequent LOOKUP operations.  Just as in the difficult task case of determining how far COMPOUND
   processing has proceeded.  Therefore,
   attribute caching, inconsistencies may arise among the various client should avoid overly
   complex COMPOUND procedures in
   caches.  To mitigate the event effects of these inconsistencies and given
   the failure context of typical filesystem APIs, an
   operation within upper time boundary is
   maintained on how long a client name cache entry can be kept without
   verifying that the procedure.

   Each entry has not been made invalid by a directory
   change operation assumes performed by another client.

   When a "current" and "saved" filehandle client is not making changes to a directory for which there
   exist name cache entries, the client needs to periodically fetch
   attributes for that directory to ensure that it is
   available as part of not being
   modified.  After determining that no modification has occurred, the execution context of
   expiration time for the compound request.
   Operations associated name cache entries may set, change, or return be updated
   to be the current filehandle.  The
   "saved" filehandle time plus the name cache staleness bound.

   When a client is used for temporary storage of making changes to a filehandle
   value and as operands for given directory, it needs to
   determine whether there have been changes made to the RENAME directory by
   other clients.  It does this by using the change attribute as
   reported before and LINK operations.

13.3.  Synchronous Modifying Operations

   NFS version 4 operations that modify after the file system are synchronous.
   When an directory operation is successfully completed at the server, in the client
   can depend that any data associated with
   change_info4 value returned for the request is now on stable
   storage (the one exception operation.  The server is in able to
   communicate to the case of client whether the file change_info4 data in a WRITE
   operation is provided
   atomically with respect to the UNSTABLE option specified).

   This implies that any previous operations within directory operation.  If the same compound
   request change
   values are also reflected in stable storage.  This behavior enables provided atomically, the client's ability client is then able to recover from a partially executed compound
   request which may resulted from the failure of compare
   the server.  For pre-operation change value with the change value in the client's
   name cache.  If the comparison indicates that the directory was
   updated by another client, the name cache associated with the
   modified directory is purged from the client.  If the comparison
   indicates no modification, the name cache can be updated on the
   client to reflect the directory operation and the associated timeout

Draft Specification      NFS version 4 Protocol                July              August 2002

   example, if

   extended.  The post-operation change value needs to be saved as the
   basis for future change_info4 comparisons.

   As demonstrated by the scenario above, name caching requires that the
   client revalidate name cache data by inspecting the change attribute
   of a compound request contains operations A directory at the point when the name cache item was cached.
   This requires that the server update the change attribute for
   directories when the contents of the corresponding directory is
   modified.  For a client to use the change_info4 information
   appropriately and B correctly, the server must report the pre and post
   operation change attribute values atomically.  When the server is
   unable to send a response to report the client, depending on before and after values atomically with respect
   to the
   progress directory operation, the server made must indicate that fact in servicing the request
   change_info4 return value.  When the result of both
   operations may be reflected in stable storage or just operation A may
   be reflected.  The server must information is not atomically
   reported, the client should not assume that other clients have just not
   changed the directory.

9.8.  Directory Caching

   The results of operation
   B in stable storage.

13.4.  Operation Values

   The READDIR operations encoded may be used to avoid subsequent
   READDIR operations.  Just as in the COMPOUND procedure are identified by
   operation values. cases of attribute and name
   caching, inconsistencies may arise among the various client caches.
   To avoid overlap with mitigate the RPC procedure numbers,
   operations 0 (zero) effects of these inconsistencies, and 1 are not defined.  Operation 2 given the
   context of typical filesystem APIs, the following rules should be
   followed:

   o    Cached READDIR information for a directory which is not
   defined but reserved for future use with minor versioning.

Draft Specification      NFS version 4 Protocol                July 2002

14.  NFS Version 4 Procedures

14.1.  Procedure 0: NULL - No Operation

   SYNOPSIS

     <null>

   ARGUMENT

     void;

   RESULT

     void;

   DESCRIPTION

     Standard NULL procedure.  Void argument, void response. obtained
        in a single READDIR operation must always be a consistent
        snapshot of directory contents.  This
     procedure has no functionality associated with it.  Because is determined by using a
        GETATTR before the first READDIR and after the last of this
     it READDIR
        that contributes to the cache.

   o    An upper time boundary is sometimes used maintained to measure indicate the overhead length of processing
        time a
     service request.  Therefore, directory cache entry is considered valid before the server should ensure
        client must revalidate the cached information.

   The revalidation technique parallels that no
     unnecessary work is done discussed in servicing this procedure.

   ERRORS

     None.

Draft Specification      NFS version 4 Protocol                July 2002

14.2.  Procedure 1: COMPOUND - Compound Operations

   SYNOPSIS

     compoundargs -> compoundres

   ARGUMENT

     union nfs_argop4 switch (nfs_opnum4 argop) {
             case <OPCODE>: <argument>;
             ...
     };

     struct COMPOUND4args {
             utf8string      tag;
             uint32_t        minorversion;
             nfs_argop4      argarray<>;
     };

   RESULT

     union nfs_resop4 switch (nfs_opnum4 resop){ the case <OPCODE>: <result>;
             ...
     };

     struct COMPOUND4res {
             nfsstat4        status;
             utf8string      tag;
             nfs_resop4      resarray<>;
     };

   DESCRIPTION

     The COMPOUND procedure of
   name caching.  When the client is used to combine one or more not changing the directory in
   question, checking the change attribute of the NFS
     operations into a single RPC request. directory with GETATTR
   is adequate.  The main NFS RPC program has
     two main procedures: NULL and COMPOUND.  All other operations use lifetime of the COMPOUND procedure as cache entry can be extended at
   these checkpoints.  When a wrapper.

     The COMPOUND procedure client is used modifying the directory, the
   client needs to combine individual operations
     into a single RPC request.  The server interprets each of use the
     operations in turn. change_info4 data to determine whether there
   are other clients modifying the directory.  If an operation it is executed by determined that
   no other client modifications are occurring, the server and client may update
   its directory cache to reflect its own changes.

   As demonstrated previously, directory caching requires that the status
   client revalidate directory cache data by inspecting the change
   attribute of that operation is NFS4_OK, then a directory at the next operation in point when the directory was cached.
   This requires that the COMPOUND procedure is executed.  The server continues this
     process until there are no more operations to be executed or one update the change attribute for
   directories when the contents of the operations has a status value other than NFS4_OK. corresponding directory is

Draft Specification      NFS version 4 Protocol                July              August 2002

     In the processing of

   modified.  For a client to use the COMPOUND procedure, change_info4 information
   appropriately and correctly, the server may find
     that it does not have must report the available resources pre and post
   operation change attribute values atomically.  When the server is
   unable to execute any or all
     of report the operations within before and after values atomically with respect
   to the COMPOUND sequence.  In this case, directory operation, the
     error NFS4ERR_RESOURCE will be returned for server must indicate that fact in the particular
     operation within
   change_info4 return value.  When the COMPOUND procedure where information is not atomically
   reported, the resource
     exhaustion occurred.  This assumes client should not assume that all previous operations
     within the COMPOUND sequence other clients have been evaluated successfully.  The
     results for all of not
   changed the evaluated operations must be returned to directory.

Draft Specification      NFS version 4 Protocol              August 2002

10.  Minor Versioning

   To address the
     client.

     The server will generally choose between two methods requirement of decoding an NFS protocol that can evolve as the client's request.  The first would be
   need arises, the traditional one pass
     XDR decode.  If there is an XDR decoding error in this case, NFS version 4 protocol contains the
     RPC XDR decode error would be returned.  The second method would be rules and
   framework to make an initial pass allow for future minor changes or versioning.

   The base assumption with respect to decode minor versioning is that any
   future accepted minor version must follow the basic COMPOUND request IETF process and
     then be
   documented in a standards track RFC.  Therefore, each minor version
   number will correspond to XDR decode the individual operations; an RFC.  Minor version zero of the most interesting NFS
   version 4 protocol is the decode of attributes.  In represented by this case, RFC.  The COMPOUND
   procedure will support the server may
     encounter an XDR decode error during encoding of the second pass.  In this
     case, minor version being
   requested by the server would return client.

   The following items represent the error NFS4ERR_BADXDR to signify basic rules for the decode error.

     The COMPOUND arguments contain development of
   minor versions.  Note that a "minorversion" field.  The initial
     and default value for this field is 0 (zero).  This field will be
     used by future minor versions such that the client can communicate version may decide to
   modify or add to the server what following rules as part of the minor version is being requested.  If the server
     receives a COMPOUND procedure with a minorversion field value that
     it does
   definition.

   1    Procedures are not support, the server MUST return an error of
     NFS4ERR_MINOR_VERS_MISMATCH and a zero length resultdata array.

     Contained within added or deleted

        To maintain the COMPOUND results is a "status" field.  If general RPC model, NFS version 4 minor versions
        will not add to or delete procedures from the
     results array length is non-zero, this status must be equivalent NFS program.

   2    Minor versions may add operations to the status COMPOUND and
        CB_COMPOUND procedures.

        The addition of the last operation that was executed within operations to the COMPOUND procedure.  Therefore, if an operation incurred an error
     then the "status" value will be the same error value as is being
     returned for the operation that failed.

     Note that operations, 0 (zero) and 1 (one) are CB_COMPOUND
        procedures does not defined for affect the
     COMPOUND procedure.  If RPC model.

   2.1  Minor versions may append attributes to GETATTR4args, bitmap4,
        and GETATTR4res.

        This allows for the server receives an operation array with
     either of these included, an error expansion of NFS4ERR_NOTSUPP must be
     returned.  Operation 2 is not defined but reserved the attribute model to allow
        for future
     definition and use with minor versioning.  If growth or adaptation.

   2.2  Minor version X must append any new attributes after the server receives a
     operation last
        documented attribute.

        Since attribute results are specified as an opaque array that contains operation 2 and the minorversion
     field has a value of 0 (zero), an error
        per-attribute XDR encoded results, the complexity of NFS4ERR_NOTSUPP is
     returned.  If an operation array contains an operation 2 and adding new
        attributes in the
     minorversion field is non-zero and midst of the server does current definitions will be too
        burdensome.

   3    Minor versions must not support the
     minor version, modify the server returns an error structure of
     NFS4ERR_MINOR_VERS_MISMATCH.  Therefore, the
     NFS4ERR_MINOR_VERS_MISMATCH error takes precedence over all other
     errors.

     It is possible that the server receives a request that contains an
     operation that is beyond the last defined operation (e.g. existing
        operation's arguments or results.

Draft Specification      NFS version 4 Protocol                July              August 2002

     OP_WRITE).  In this case, the server obviously will fail the
     unknown operation.  If this occurs, the server will return an
     operation "opcode" that is 1 greater than the largest defined
     operation.  For example,

        Again the server would return an opcode complexity of
     OP_WRITE + 1.  The server would then return handling multiple structure definitions
        for a status of
     NFS4ERR_NOTSUPP to indicate an single operation that is not defined and
     therefore not supported.

     The definition too burdensome.  New operations should
        be added instead of modifying existing structures for a minor
        version.

        This rule does not preclude the "tag" following adaptations in the request is left a minor
        version.

        o    adding bits to the
     implementor.  It may be used flag fields such as new attributes to summarize the content of the
     compound request for
             GETATTR's bitmap4 data type

        o    adding bits to existing attributes like ACLs that have flag
             words

        o    extending enumerated types (including NFS4ERR_*) with new
             values

   4    Minor versions may not modify the benefit structure of packet sniffers and engineers
     debugging implementations.  However, existing
        attributes.

   5    Minor versions may not delete operations.

        This prevents the value potential reuse of "tag" a particular operation
        "slot" in a future minor version.

   6    Minor versions may not delete attributes.

   7    Minor versions may not delete flag bits or enumeration values.

   8    Minor versions may declare an operation as mandatory to NOT
        implement.

        Specifying an operation as "mandatory to not implement" is
        equivalent to obsoleting an operation.  For the
     response MUST client, it means
        that the operation should not be sent to the same value as provided in server.  For the request.

   IMPLEMENTATION

     Since
        server, an NFS error of any type may occur after only a portion of the
     operations have been evaluated, the client must can be prepared returned as opposed to
     recover from any failure.  If "dropping"
        the source request as an XDR decode error.  This approach allows for
        the obsolescence of an NFS4ERR_RESOURCE
     error was operation while maintaining its structure
        so that a complex future minor version can reintroduce the operation.

   8.1  Minor versions may declare attributes mandatory to NOT
        implement.

   8.2  Minor versions may declare flag bits or lengthy set of operations, it is likely enumeration values as
        mandatory to NOT implement.

Draft Specification      NFS version 4 Protocol              August 2002

   9    Minor versions may downgrade features from mandatory to
        recommended, or recommended to optional.

   10   Minor versions may upgrade features from optional to recommended
        or recommended to mandatory.

   11   A client and server that
     if support minor version X must support
        minor versions 0 (zero) through X-1 as well.

   12   No new features may be introduced as mandatory in a minor
        version.

        This rule allows for the number introduction of operations were reduced new functionality and
        forces the server would be able use of implementation experience before designating a
        feature as mandatory.

   13   A client MUST NOT attempt to evaluate them successfully.  Therefore, use a stateid, filehandle, or
        similar returned object from the client is
     responsible COMPOUND procedure with minor
        version X for dealing another COMPOUND procedure with this type of complexity in recovery.

   ERRORS

     All errors defined in the protocol minor version Y,
        where X != Y.

Draft Specification      NFS version 4 Protocol                July              August 2002

14.2.1.  Operation 3: ACCESS - Check Access Rights

   SYNOPSIS

     (cfh), accessreq -> supported, accessrights

   ARGUMENT

     const ACCESS4_READ      = 0x00000001;
     const ACCESS4_LOOKUP    = 0x00000002;
     const ACCESS4_MODIFY    = 0x00000004;
     const ACCESS4_EXTEND    = 0x00000008;
     const ACCESS4_DELETE    = 0x00000010;
     const ACCESS4_EXECUTE   = 0x00000020;

     struct ACCESS4args {
             /* CURRENT_FH: object */
             uint32_t        access;
     };

   RESULT

     struct ACCESS4resok {
             uint32_t        supported;
             uint32_t        access;
     };

     union ACCESS4res switch (nfsstat4 status) {
      case NFS4_OK:
              ACCESS4resok   resok4;
      default:
              void;
     };

   DESCRIPTION

     ACCESS determines the access rights that a user, as identified by
     the credentials

11.  Internationalization

   The primary issue in the RPC request, has which NFS needs to deal with
   internationalization, or I18N, is with respect to the file
     system object specified by names and
   other strings as used within the current filehandle. protocol.  The client
     encodes the set choice of string
   representation must allow reasonable name/string access rights that are to be checked in the bit
     mask "access". clients
   which use various languages.  The server checks UTF-8 encoding of the permissions encoded UCS as
   defined by [ISO10646] allows for this type of access and follows the
   policy described in "IETF Policy on Character Sets and Languages",
   [RFC2277].  This choice is explained further in the
     bit mask.  If following.

11.1.  Universal Versus Local Character Sets

   [RFC1345] describes a status table of NFS4_OK is returned, two 16 bit masks are
     included in the response.  The first, "supported", represents the
     access rights for which the server can verify reliably.  The
     second, "access", represents the access rights available to the
     user characters for the filehandle provided.  On success, the current
     filehandle retains its value.

Draft Specification      NFS version 4 Protocol                July 2002

     Note that the supported field will contain only as many values as
     was originally sent in the arguments.  For example, if the client
     sends an ACCESS operation different
   languages (the bit encodings match Unicode, though of course
   [RFC1345] is somewhat out of date with only the ACCESS4_READ respect to current Unicode
   assignments).  Each character from each language has a unique 16 bit
   value set and in the server supports 16 bit character set.  Thus this value, the server will return only
     ACCESS4_READ even if it could have reliably checked other values.

     The results table can be thought of this operation are necessarily advisory in nature.
     A return status
   as a universal character set.  [RFC1345] then talks about groupings
   of subsets of NFS4_OK and the appropriate entire 16 bit character set in into "Charset Tables".
   For example one might take all the Greek characters from the 16 bit
     mask does not imply that such access will be allowed
   table (which are consecutively allocated), and normalize their
   offsets to a table that fits in 7 bits.  Thus it is determined that
   "lower case alpha" is in the file
     system object same position as "upper case a" in the future. This
   US-ASCII table, and "upper case alpha" is because access rights can be
     revoked by in the server at any time.

     The following access permissions may be requested:

   ACCESS4_READ    Read data from file or read a directory.

   ACCESS4_LOOKUP  Look up a name same position as
   "lower case a" in a directory (no meaning the US-ASCII table.

   These normalized subset character sets can be thought of as "local
   character sets", suitable for non-
                   directory objects).

   ACCESS4_MODIFY  Rewrite existing file data or modify existing
                   directory entries.

   ACCESS4_EXTEND  Write new data or add directory entries.

   ACCESS4_DELETE  Delete an existing directory entry (no meaning for
                   non-directory objects).

   ACCESS4_EXECUTE Execute file (no meaning operating system locale.

   Local character sets are not suitable for a directory).

   On success, the current filehandle retains its value.

   IMPLEMENTATION

     For the NFS version 4 protocol, the use of the ACCESS procedure
     when opening protocol.  Consider
   someone who creates a regular file is deprecated with a name in favor of using OPEN.

     In general, it is not sufficient for the client to attempt a Swedish character set.
   If someone else later goes to
     deduce access permissions by inspecting the uid, gid, and mode
     fields file with their locale set
   to the Swedish language, then there are no problems.  But if someone
   in say the file attributes or by attempting US-ASCII locale goes to interpret access the
     contents of file, the ACL attribute.  This is file name
   will look very different, because the server may
     perform uid or gid mapping or enforce additional access control
     restrictions.  It is also possible that Swedish characters in the server may not 7 bit
   table will now be represented in US-ASCII characters on the same ID space as display.
   It would be preferable to give the client.  In these cases (and perhaps
     others), US-ASCII user a way to display the client can not reliably perform an access check with
     only current
   file attributes. name using Swedish glyphs. In order to do that, the NFS version 2 protocol, the only reliable way protocol
   would have to determine
     whether an include the locale with the file name on each operation was allowed was
   to try it and see if it
     succeeded or failed.  Using create a file.

   However, the ACCESS procedure complexity burden of defining such locales in a way that
   could be understood by all clients and servers, and maintaining them
   in the face of changes would be considerable.  A better solution is
   desirable.

   If the NFS version 4 protocol, the client can ask protocol used a universal 16 bit or 32 bit
   character set (or an encoding of a 16 bit or 32 bit character set
   into octets), then the server to indicate whether or and client need not one or more classes care if the locale
   of operations are permitted. the user accessing the file is different than the locale of the
   user who created the file.  The ACCESS unique 16 bit or 32 bit encoding of

Draft Specification      NFS version 4 Protocol                July              August 2002

     operation is provided to allow clients to check before doing a
     series of operations which will result in an access failure.  The
     OPEN operation provides a point where

   the server can verify access
     to character allows for determination of what language the file object character
   is from and method also how to return display that information to character on the client.  The ACCESS operation is still useful for directory
     operations or
   server need not know what locales are used.

11.2.  Overview of Universal Character Set Standards

   The previous section makes a case for use in using a universal character
   set.  This section makes the case for using UTF-8 as the UNIX API "access" is used on specific
   universal character set for the client.

     The information returned by NFS version 4 protocol.

   [RFC2279] discusses UTF-* (UTF-8 and other UTF-XXX encodings),
   Unicode, and UCS-*.  There are two standards bodies managing
   universal code sets:

   o    ISO/IEC which has the server in response standard 10646-1

   o    Unicode which has the Unicode standard

   Both standards bodies have pledged to an ACCESS
     call track each other's assignments
   of character codes.

   The following is not permanent.  It was correct at a brief analysis of the exact time that various standards.

   UCS       Universal Character Set.  This is ISO/IEC 10646-1: "a
             multi-octet character set called the
     server performed Universal Character
             Set (UCS), which encompasses most of the checks, but not necessarily afterwards.  The
     server can revoke access permission at any time.

     The client should use world's writing
             systems."

   UCS-2     a two octet per character encoding that addresses the effective credentials first
             2^16 characters of UCS. Currently there are no UCS
             characters beyond that range.

   UCS-4     a four octet per character encoding that permits the user
             encoding of up to
     build 2^31 characters.

   UTF       UTF is an abbreviation of the authentication information term "UCS transformation
             format" and is used in the ACCESS request used to
     determine access rights.  It is the effective user and group
     credentials that are used in subsequent read and write operations.

     Many implementations do not directly support the ACCESS4_DELETE
     permission.  Operating systems like UNIX will ignore the
     ACCESS4_DELETE bit if set on an access request on a non-directory
     object.  In these systems, delete permission on a file is
     determined by the access permissions on the directory in which the
     file resides, instead naming of being determined by the permissions various standards for
             encoding of UCS characters as described below.

   UTF-1     Only historical interest; it has been removed from 10646-1

   UTF-7     Encodes the
     file itself.  Therefore, the mask returned enumerating which access
     rights can be determined will have the ACCESS4_DELETE value set to
     0.  This indicates to the client that entire "repertoire" of UCS "characters using
             only octets with the server was unable to
     check that particular access right.  The ACCESS4_DELETE higher order bit in the
     access mask returned will then be ignored clear".  [RFC2152]
             describes UTF-7. UTF-7 accomplishes this by reserving one
             of the client.

   ERRORS

     NFS4ERR_ACCESS
     NFS4ERR_BADHANDLE
     NFS4ERR_BADXDR
     NFS4ERR_DELAY
     NFS4ERR_FHEXPIRED
     NFS4ERR_IO
     NFS4ERR_MOVED
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE
     NFS4ERR_WRONGSEC 7bit US-ASCII characters as a "shift" character to
             indicate non-US-ASCII characters.

Draft Specification      NFS version 4 Protocol                July              August 2002

14.2.2.  Operation 4: CLOSE - Close File

   SYNOPSIS

     (cfh), seqid, open_stateid -> open_stateid

   ARGUMENT

     struct CLOSE4args {
             /* CURRENT_FH: object */
             seqid4          seqid
             stateid4        open_stateid;
     };

   RESULT

     union CLOSE4res switch (nfsstat4 status) {
      case NFS4_OK:
              stateid4       open_stateid;
      default:
              void;
     };

   DESCRIPTION

     The CLOSE operation releases share reservations for the regular or
     named attribute file as specified by the current filehandle.  The
     share reservations and other state information released at

   UTF-8     Unlike UTF-7, uses all 8 bits of the
     server octets. US-ASCII
             characters are encoded as a result of this CLOSE is only associated before unchanged. Any octet with
             the
     supplied stateid. high bit cleared can only mean a US-ASCII character.
             The sequence id provides for the correct
     ordering. State associated with other OPENs high bit set means that a UCS character is not affected.

     If record locks being
             encoded.

   UTF-16    Encodes UCS-4 characters into UCS-2 characters using a
             reserved range in UCS-2.

   Unicode   Unicode and UCS-2 are held, the client SHOULD release all locks
     before issuing a CLOSE.  The server MAY free all outstanding locks
     on CLOSE but some servers may not support same; [RFC2279] states:

        Up to the CLOSE of a file present time, changes in Unicode and amendments
        to ISO/IEC 10646 have tracked each other, so that
     still has record locks held.  The server MUST return failure if any
     locks would exist after the CLOSE.

     On success, the current filehandle retains its value.

   IMPLEMENTATION

     Even though CLOSE returns a stateid,
        character repertoires and code point assignments have
        remained in sync.  The relevant standardization committees
        have committed to maintain this stateid is not very useful synchronism.

11.3.  Difficulties with UCS-4, UCS-2, Unicode

   Adapting existing applications, and filesystems to
     the client multi-octet
   schemes like UCS and should Unicode can be treated as deprecated.  CLOSE "shuts down"
     the state associated difficult.  A significant amount
   of code has been written to process streams of bytes. Also there are
   many existing stored objects described with all OPENs for 7 bit or 8 bit
   characters. Doubling or quadrupling the file by a single

Draft Specification      NFS version 4 Protocol                July 2002

     open_owner.  As noted above, CLOSE will either release all file
     locking state or return bandwidth and storage
   requirements seems like an error.  Therefore, the stateid returned
     by CLOSE is not useful expensive way to accomplish I18N.

   UCS-2 and Unicode are "only" 16 bits long.  That might seem to be
   enough but, according to [Unicode1], 49,194 Unicode characters are
   already assigned.  According to [Unicode2] there are still more
   languages that need to be added.

11.4.  UTF-8 and its solutions

   UTF-8 solves problems for operations NFS that follow.

   ERRORS

     NFS4ERR_BADHANDLE
     NFS4ERR_BAD_SEQID
     NFS4ERR_BAD_STATEID
     NFS4ERR_BADXDR
     NFS4ERR_DELAY
     NFS4ERR_EXPIRED
     NFS4ERR_FHEXPIRED
     NFS4ERR_GRACE
     NFS4ERR_INVAL
     NFS4ERR_ISDIR
     NFS4ERR_LEASE_MOVED
     NFS4ERR_LOCKS_HELD
     NFS4ERR_MOVED
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_OLD_STATEID
     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE
     NFS4ERR_STALE_STATEID exist with the use of UCS and
   Unicode.  UTF-8 will encode 16 bit and 32 bit characters in a way
   that will be compact for most users. The encoding table from UCS-4 to
   UTF-8, as copied from [RFC2279]:

      UCS-4 range (hex.)           UTF-8 octet sequence (binary)
    0000 0000-0000 007F   0xxxxxxx
    0000 0080-0000 07FF   110xxxxx 10xxxxxx
    0000 0800-0000 FFFF   1110xxxx 10xxxxxx 10xxxxxx

    0001 0000-001F FFFF   11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
    0020 0000-03FF FFFF   111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
    0400 0000-7FFF FFFF   1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
   10xxxxxx

   See [RFC2279] for precise encoding and decoding rules. Note because

Draft Specification      NFS version 4 Protocol                July              August 2002

14.2.3.  Operation 5: COMMIT - Commit Cached Data

   SYNOPSIS

     (cfh), offset, count -> verifier

   ARGUMENT

     struct COMMIT4args {
             /* CURRENT_FH: file */
             offset4         offset;
             count4          count;
     };

   RESULT

     struct COMMIT4resok {
             verifier4       writeverf;
     };

     union COMMIT4res switch (nfsstat4 status) {
      case NFS4_OK:
              COMMIT4resok   resok4;
      default:
              void;
     };

   DESCRIPTION

     The COMMIT operation forces or flushes data

   of UTF-16, the algorithm from Unicode/UCS-2 to stable storage UTF-8 needs to account
   for the file specified by the current file handle.  The flushed data is reserved range between D800 and DFFF.

   Note that which was previously written with a WRITE operation which had the stable field set 16 bit UCS or Unicode characters require no more than 3
   octets to UNSTABLE4.

     The offset specifies the position within the file where encode into UTF-8

   Interestingly, UTF-8 has room to handle characters larger than 31
   bits, because the flush leading octet of form:

           1111111x

   is not defined. If needed, ISO could either use that octet to begin.  An offset value
   indicate a sequence of 0 (zero) means an encoded 8 octet character, or perhaps use
   11111110 to flush data
     starting at permit the beginning next octet to indicate an even more expandable
   character set.

   So using UTF-8 to represent character encodings means never having to
   run out of the file. room.

11.5.  Normalization

   The count specifies the
     number of bytes of data client and server operating environments may differ in their
   policies and operational methods with respect to flush.  If count is 0 (zero), character
   normalization (See [Unicode1] for a flush
     from offset discussion of normalization
   forms).  This difference may also exist between applications on the
   same client.  This adds to the end difficulty of the file is done.

     The server returns providing a write verifier upon successful completion of single
   normalization policy for the COMMIT.  The write verifier protocol that allows for maximal
   interoperability.  This issue is used by the client similar to determine
     if the character case issues
   where the server has restarted may or rebooted between the initial
     WRITE(s) may not support case insensitive file name
   matching and may or may not preserve the COMMIT. character case when storing
   file names.  The client protocol does this by comparing the
     write verifier returned from the initial writes and the verifier
     returned by not mandate a particular behavior but
   allows for the COMMIT procedure. various permutations.

   The server must vary NFS version 4 protocol does not mandate the value use of the write verifier at each server event or instantiation that
     may lead to a loss particular
   normalization form at this time.  A later revision of uncommitted data.  Most commonly this occurs
     when the server is rebooted; however, other events at
   specification may specify a particular normalization form.
   Therefore, the server

Draft Specification      NFS version 4 Protocol                July 2002 and client can expect that they may result in uncommitted data loss as well.

     On success, the current filehandle retains its value.

   IMPLEMENTATION

     The COMMIT procedure is similar in operation receive
   unnormalized characters within protocol requests and semantics to responses.  If
   the
     POSIX fsync(2) system call that synchronizes a file's state with operating environment requires normalization, then the disk (file data and metadata is flushed to disk or stable
     storage). COMMIT performs
   implementation must normalize the same operation for a client, flushing
     any unsynchronized data and metadata on various UTF-8 encoded strings
   within the server protocol before presenting the information to an
   application (at the server's
     disk client) or stable storage for local filesystem (at the specified file.  Like fsync(2), it
     may be that there is some modified data or no modified data to
     synchronize.  The data may have been synchronized by server).

11.6.  UTF-8 Related Errors

   Where the server's
     normal periodic buffer synchronization activity.  COMMIT client sends an invalid UTF-8 string, the server should
   return NFS4_OK, unless there has been an unexpected NFS4ERR_INVAL error.

     COMMIT differs from fsync(2)  This includes cases in that it is possible for which
   inappropriate prefixes are detected and where the client
     to flush count includes
   trailing bytes that do not constitute a range of full UCS character.

   Where the file (most likely triggered client supplied string is valid UTF-8 but contains

Draft Specification      NFS version 4 Protocol              August 2002

   characters that are not supported by the server as a buffer-
     reclamation scheme value for that
   string (e.g. names containing characters that have more than two
   octets on a filesystem that supports Unicode characters only), the client before file has been completely
     written).

     The
   server implementation of COMMIT should return an NFS4ERR_BADCHAR error.

   Where a UTF-8 string is reasonably simple.  If the
     server receives used as a full file COMMIT request, that is starting at
     offset 0 name, and count 0, it should do the equivalent filesystem,
   while supporting all of fsync()'ing
     the file.  Otherwise, it should arrange to have the cached data in characters within the range specified by offset and count name, does not
   allow that particular name to be flushed to stable
     storage.  In both cases, any metadata associated with used, the file must
     be flushed to stable storage before returning.  It is not an error
     for there to be nothing to flush on should return the server.
   error NFS4ERR_BADNAME.  This means that
     the data and metadata that needed to be flushed have already been
     flushed or lost during includes situations in which the last server failure.

     The client implementation of COMMIT is a little more complex.
     There are two reasons for wanting to commit
   filesystem imposes a client buffer normalization constraint on name strings, but
   will also include such situations as filesystem prohibitions of "."
   and ".." as file names for certain operations, and other such
   constraints.

Draft Specification      NFS version 4 Protocol              August 2002

12.  Error Definitions

   NFS error numbers are assigned to
     stable storage.  The first is failed operations within a compound
   request.  A compound request contains a number of NFS operations that the client wants to reuse
   have their results encoded in sequence in a
     buffer.  In this case, the offset and count compound reply.  The
   results of successful operations will consist of an NFS4_OK status
   followed by the buffer are sent
     to encoded results of the server operation.  If an NFS
   operation fails, an error status will be entered in the COMMIT request.  The server then flushes any
     cached data based on the offset and count, reply and flushes any metadata
     associated with the file.  It then returns the status
   compound request will be terminated.

   A description of each defined error follows:

   NFS4_OK               Indicates the flush
     and the write verifier. operation completed successfully.

   NFS4ERR_ACCESS        Permission denied. The other reason for caller does not have the client
                         correct permission to
     generate a COMMIT is for a full file flush, such as may be done at
     close.  In this case, the client would gather all of perform the buffers
     for requested
                         operation. Contrast this file that contain uncommitted data, do the COMMIT
     operation with an offset of 0 and count of 0, and then free all of
     those buffers.  Any other dirty buffers would be sent NFS4ERR_PERM,
                         which restricts itself to the server
     in the normal fashion.

     After a buffer owner or privileged
                         user permission failures.

   NFS4ERR_ATTRNOTSUPP   An attribute specified is written not supported by the client with the stable parameter
     set
                         server.  Does not apply to UNSTABLE4, the buffer must be considered as modified GETATTR
                         operation.

   NFS4ERR_BADCHAR       A UTF-8 string contains a character which is
                         not supported by the
     client until server in the buffer has either been flushed via a COMMIT

Draft Specification context in
                         which it being used.

   NFS4ERR_BAD_COOKIE    READDIR cookie is stale.

   NFS4ERR_BADHANDLE     Illegal NFS version 4 Protocol                July 2002

     operation or written via filehandle. The filehandle failed
                         internal consistency checks.

   NFS4ERR_BADNAME       A name string in a WRITE operation with stable parameter
     set to FILE_SYNC4 or DATA_SYNC4. This is done to prevent request consists of valid
                         UTF-8 characters supported by the buffer
     from being freed and reused before server but
                         the data name is not supported by the server as a
                         valid name for current operation.

   NFS4ERR_BADOWNER      An owner, owner_group, or ACL attribute value
                         can not be flushed translated to
     stable storage on local representation.

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

     When a response is returned from either

   NFS4ERR_BAD_RANGE     The range for a WRITE LOCK, LOCKT, or a COMMIT LOCKU operation and it contains a write verifier that
                         is different than
     previously returned by the server, the client will need not appropriate to
     retransmit all of the buffers containing uncommitted cached data to allowable range of
                         offsets for the server.  How this is to be done is up to the implementor.  If
     there is only one buffer of interest, then it should probably be
     sent back over

   NFS4ERR_BAD_SEQID     The sequence number in a WRITE locking request with the appropriate stable
     parameter.  If there is more than one buffer, it might be
     worthwhile retransmitting all of the buffers in WRITE requests with
     the stable parameter set to UNSTABLE4 and then retransmitting the
     COMMIT operation to flush all of the data on the server to stable
     storage.  The timing of these retransmissions is left to the
     implementor.

     The above description applies to page-cache-based systems as well
     as buffer-cache-based systems.  In those systems,
                         neither the virtual
     memory system will need to be modified instead of next expected number or the buffer cache.

   ERRORS

     NFS4ERR_ACCESS
     NFS4ERR_BADHANDLE
     NFS4ERR_BADXDR
     NFS4ERR_FHEXPIRED
     NFS4ERR_INVAL
     NFS4ERR_IO
     NFS4ERR_ISDIR
     NFS4ERR_MOVED
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_RESOURCE
     NFS4ERR_ROFS
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE
     NFS4ERR_WRONGSEC last

Draft Specification      NFS version 4 Protocol                July              August 2002

14.2.4.  Operation 6: CREATE - Create a Non-Regular File Object

   SYNOPSIS

     (cfh), name, type, attrs -> (cfh), change_info, attrs_set

   ARGUMENT

     union createtype4 switch (nfs_ftype4 type) {
      case NF4LNK:
              linktext4      linkdata;
      case NF4BLK:
      case NF4CHR:
              specdata4      devdata;
      case NF4SOCK:
      case NF4FIFO:
      case NF4DIR:
              void;
     };

     struct CREATE4args {
             /* CURRENT_FH: directory

                         number processed.

   NFS4ERR_BAD_STATEID   A stateid generated by the current server
                         instance, but which does not designate any
                         locking state (either current or superseded)
                         for creation */
             component4      objname;
             createtype4     objtype;
             fattr4          createattrs;
     };

   RESULT

     struct CREATE4resok {
             change_info4    cinfo;
             bitmap4         attrset;        /* attributes set */
     };

     union CREATE4res switch (nfsstat4 status) {
      case NFS4_OK:
              CREATE4resok resok4;
      default:
              void;
     };

   DESCRIPTION a current lockowner-file pair, was used.

   NFS4ERR_BADXDR        The CREATE server encountered an XDR decoding error
                         while processing an operation.

   NFS4ERR_CLID_INUSE    The SETCLIENTID operation creates has found that a non-regular file object
                         client id is already in a
     directory with a given name. use by another client.

   NFS4ERR_DEADLOCK      The OPEN procedure MUST be used server has been able to
     create determine a regular file.

     The objname specifies the name file
                         locking deadlock condition for the new object. a blocking lock
                         request.

   NFS4ERR_DELAY         The objtype
     determines server initiated the type of object request, but was not
                         able to be created: directory, symlink,

Draft Specification      NFS version 4 Protocol                July 2002

     etc.

     If an object of the same name already exists complete it in a timely fashion. The
                         client should wait and then try the directory, the
     server will return the error NFS4ERR_EXIST.

     For the directory where the request
                         with a new file object was created, the RPC transaction ID.  For example,
                         this error should be returned from a server
     returns change_info4 information in cinfo.  With the atomic field
     of the change_info4 struct,
                         that supports hierarchical storage and receives
                         a request to process a file that has been
                         migrated. In this case, the server will indicate if should start
                         the before immigration process and after change attributes were obtained atomically respond to client
                         with respect this error.  This error may also occur
                         when a necessary delegation recall makes
                         processing a request in a timely fashion
                         impossible.

   NFS4ERR_DENIED        An attempt to the lock a file object creation.

     If the objname has is denied.  Since
                         this may be a length of 0 (zero), or if objname does not
     obey the UTF-8 definition, temporary condition, the error NFS4ERR_INVAL will be
     returned.

     The current filehandle client
                         is replaced by that of encouraged to retry the new object.

     The createattrs specifies lock request until
                         the initial set of attributes for lock is accepted.

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

   NFS4ERR_EXIST         File exists. The set of attributes may include any writable attribute
     valid for the object type. When the operation file specified already exists.

   NFS4ERR_EXPIRED       A lease has expired that is successful, being used in the
     server will return
                         current operation.

   NFS4ERR_FBIG          File too large. The operation would have caused
                         a file to grow beyond the client an attribute mask signifying which
     attributes were successfully set for the object.

   IMPLEMENTATION

     If the client desires to set attribute values after server's limit.

   NFS4ERR_FHEXPIRED     The filehandle provided is volatile and has
                         expired at the create, a
     SETATTR server.

   NFS4ERR_FILE_OPEN     The operation can not be added to successfully processed

Draft Specification      NFS version 4 Protocol              August 2002

                         because a file involved in the COMPOUND request so that operation is
                         currently open.

   NFS4ERR_GRACE         The server is in its recovery or grace period
                         which should match the
     appropriate attributes will be set.

     It may be that lease period of the server's implementation places special meaning
                         server.

   NFS4ERR_INVAL         Invalid argument or unsupported argument for an
                         operation. Two examples are attempting a
                         READLINK on the names "." and ".." where they refer an object other than a symbolic
                         link or attempting to special directories.
     If SETATTR a time field on a
                         server that does not support this is the case and operation.

   NFS4ERR_IO            I/O error. A hard error (for example, a disk
                         error) occurred while processing the client requests to CREATE requested
                         operation.

   NFS4ERR_ISDIR         Is a directory. The caller specified a
                         directory
     (or other object) in a non-directory operation.

   NFS4ERR_LEASE_MOVED   A lease being renewed is associated with these names, a
                         filesystem that has been migrated to a new
                         server.

   NFS4ERR_LOCKED        A read or write operation was attempted on a
                         locked file.

   NFS4ERR_LOCK_NOTSUPP  Server does not support atomic upgrade or
                         downgrade of locks.

   NFS4ERR_LOCK_RANGE    A lock request is operating on a sub-range of a
                         current lock for the server may return
     NFS4ERR_INVAL.  However, if lock owner and the server
                         does not place special
     meaning on these names support this type of request.

   NFS4ERR_LOCKS_HELD    A CLOSE was attempted and a file object already exists with a
     matching name, locks would
                         exist after the CLOSE.

   NFS4ERR_MINOR_VERS_MISMATCH
                         The server may has received a request that
                         specifies an unsupported minor version.  The
                         server must return NFS4ERR_EXIST.

   ERRORS

     NFS4ERR_ACCESS
     NFS4ERR_ATTRNOTSUPP
     NFS4ERR_BADHANDLE
     NFS4ERR_BADTYPE
     NFS4ERR_BADXDR
     NFS4ERR_DQUOT
     NFS4ERR_EXIST
     NFS4ERR_FHEXPIRED
     NFS4ERR_INVAL
     NFS4ERR_IO a COMPOUND4res with a zero
                         length operations result array.

   NFS4ERR_MLINK         Too many hard links.

   NFS4ERR_MOVED         The filesystem which contains the current
                         filehandle object has been relocated or
                         migrated to another server.  The client may
                         obtain the new filesystem location by obtaining
                         the "fs_locations" attribute for the current
                         filehandle.  For further discussion, refer to
                         the section "Filesystem Migration or

Draft Specification      NFS version 4 Protocol                July              August 2002

                         Relocation".

   NFS4ERR_NAMETOOLONG   The filename in an operation was too long.

   NFS4ERR_NODEV         No such device.

   NFS4ERR_NOENT         No such file or directory. The file or
                         directory name specified does not exist.

   NFS4ERR_NOFILEHANDLE
     NFS4ERR_NOSPC
     NFS4ERR_NOTDIR
     NFS4ERR_NOTSUPP
     NFS4ERR_RESOURCE
     NFS4ERR_ROFS
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE
     NFS4ERR_WRONGSEC

Draft Specification      NFS version 4 Protocol                July 2002

14.2.5.  Operation 7: DELEGPURGE - Purge Delegations Awaiting Recovery

   SYNOPSIS

     clientid ->

   ARGUMENT

     struct DELEGPURGE4args {
             clientid4       clientid;
     };

   RESULT

     struct DELEGPURGE4res {
             nfsstat4        status;
     };

   DESCRIPTION

     Purges all  The logical current filehandle value (or, in
                         the case of RESTOREFH, the delegations awaiting recovery for a given client.
     This is useful for clients which do not commit delegation
     information to stable storage to indicate that conflicting requests
     need saved filehandle
                         value) has not been set properly.  This may be delayed by the server awaiting recovery
                         a result of delegation
     information.

     This a malformed COMPOUND operation
                         (i.e. no PUTFH or PUTROOTFH before an operation should be used by clients
                         that record delegation
     information on stable storage on requires the client.  In this case,
     DELEGPURGE should current filehandle be issued immediately after doing delegation
     recovery on all delegations know to set).

   NFS4ERR_NO_GRACE      A reclaim of client state has fallen outside of
                         the client.  Doing so will
     notify grace period of the server.  As a result,
                         the server can not guarantee that no additional delegations for conflicting
                         state has not been provided to another client.

   NFS4ERR_NOSPC         No space left on device. The operation would
                         have caused the client
     will be recovered allowing it server's filesystem to free resources, and avoid delaying
     other clients who make requests exceed
                         its limit.

   NFS4ERR_NOTDIR        Not a directory. The caller specified a non-
                         directory in a directory operation.

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

   NFS4ERR_NOTSUPP       Operation is not supported.

   NFS4ERR_NOT_SAME      This error is returned by the unrecovered
     delegations.  The set of delegations known VERIFY operation
                         to signify that the server and attributes compared were
                         not the
     client may be different.  The reason same as provided in the client's
                         request.

   NFS4ERR_NXIO          I/O error. No such device or address.

   NFS4ERR_OLD_STATEID   A stateid which designates the locking state
                         for this is that a lockowner-file at an earlier time was
                         used.

   NFS4ERR_OPENMODE      The client may
     fail after making attempted a request which resulted in delegation but before
     it received the results and committed them to READ, WRITE, LOCK or
                         SETATTR operation not sanctioned by the client's stable
     storage.

   ERRORS

     NFS4ERR_BADXDR
     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE_CLIENTID

Draft Specification      NFS version 4 Protocol                July 2002

14.2.6.  Operation 8: DELEGRETURN - Return Delegation

   SYNOPSIS

     (cfh), stateid ->

   ARGUMENT

     struct DELEGRETURN4args {
             /* CURRENT_FH: delegated
                         passed (e.g. writing to a file */
             stateid4        stateid;
     };

   RESULT

     struct DELEGRETURN4res {
             nfsstat4        status;
     };

   DESCRIPTION

     Returns the delegation represented by opened only for
                         read).

   NFS4ERR_OP_ILLEGAL    An illegal operation value has been specified
                         in the current filehandle and
     stateid.

   ERRORS

     NFS4ERR_BAD_STATEID
     NFS4ERR_BADXDR
     NFS4ERR_EXPIRED
     NFS4ERR_OLD_STATEID
     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE_STATEID argop field of a COMPOUND or CB_COMPOUND
                         procedure.

Draft Specification      NFS version 4 Protocol                July              August 2002

14.2.7.  Operation 9: GETATTR - Get Attributes

   SYNOPSIS

     (cfh), attrbits -> attrbits, attrvals

   ARGUMENT

     struct GETATTR4args {
             /* CURRENT_FH: directory or file */
             bitmap4         attr_request;
     };

   RESULT

     struct GETATTR4resok {
             fattr4          obj_attributes;
     };

     union GETATTR4res switch (nfsstat4 status) {
      case NFS4_OK:
              GETATTR4resok  resok4;
      default:
              void;
     };

   DESCRIPTION

   NFS4ERR_PERM          Not owner. The GETATTR operation will obtain attributes for the file system
     object specified by was not allowed
                         because the current filehandle.  The client sets caller is either not a bit
     in the bitmap argument for each attribute value that it would like privileged
                         user (root) or not the server to return.  The server returns an attribute bitmap that
     indicates owner of the attribute values for which it was able to return,
     followed by target of
                         the attribute values ordered lowest attribute number
     first. operation.

   NFS4ERR_READDIR_NOSPC The server must return encoded response to a value for each attribute that the client
     requests if READDIR request
                         exceeds the attribute is supported size limit set by the server.  If initial
                         request.

   NFS4ERR_RECLAIM_BAD   The reclaim provided by the
     server client does not support an attribute or cannot approximate
                         match any of the server's state consistency
                         checks and is bad.

   NFS4ERR_RECLAIM_CONFLICT
                         The reclaim provided by the client has
                         encountered a useful
     value then it must conflict and can not return be provided.
                         Potentially indicates a misbehaving client.

   NFS4ERR_RESOURCE      For the attribute value processing of the COMPOUND procedure,
                         the server may exhaust available resources and must
                         can not set continue processing operationss within
                         the attribute bit in COMPOUND procedure.  This error will be
                         returned from the result bitmap.  The server must return an in those instances of
                         resource exhaustion related to the processing
                         of the COMPOUND procedure.

   NFS4ERR_ROFS          Read-only filesystem. A modifying operation was
                         attempted on a read-only filesystem.

   NFS4ERR_SAME          This error if it supports an attribute but cannot obtain its value.  In is returned by the NVERIFY operation
                         to signify that case no attribute values will be returned.

     All servers must support the mandatory attributes compared were
                         the same as specified provided in the section "File Attributes".

     On success, client's request.

   NFS4ERR_SERVERFAULT   An error occurred on the current filehandle retains its value.

Draft Specification server which does not
                         map to any of the legal NFS version 4 Protocol                July 2002

   IMPLEMENTATION

   ERRORS

     NFS4ERR_ACCESS
     NFS4ERR_BADHANDLE
     NFS4ERR_BADXDR
     NFS4ERR_DELAY
     NFS4ERR_FHEXPIRED
     NFS4ERR_INVAL
     NFS4ERR_IO
     NFS4ERR_MOVED
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT protocol
                         error values.  The client should translate this
                         into an appropriate error.  UNIX clients may
                         choose to translate this to EIO.

   NFS4ERR_SHARE_DENIED  An attempt to OPEN a file with a share
                         reservation has failed because of a share
                         conflict.

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

   NFS4ERR_STALE_CLIENTID A clientid not recognized by the server was
                          used in a locking or SETCLIENTID_CONFIRM
                          request.

Draft Specification      NFS version 4 Protocol                July              August 2002

14.2.8.  Operation 10: GETFH - Get Current Filehandle

   SYNOPSIS

     (cfh) -> filehandle

   ARGUMENT

     /* CURRENT_FH: */
     void;

   RESULT

     struct GETFH4resok {
             nfs_fh4         object;
     };

     union GETFH4res switch (nfsstat4 status) {
      case NFS4_OK:
             GETFH4resok     resok4;
      default:
             void;
     };

   DESCRIPTION

     This operation returns the current filehandle value.

     On success, the current filehandle retains its value.

   IMPLEMENTATION

     Operations that change the

   NFS4ERR_STALE_STATEID A stateid generated by an earlier server
                         instance was used.

   NFS4ERR_SYMLINK       The current filehandle like provided for a LOOKUP or CREATE
     do is
                         not automatically return the new filehandle as a result.  For
     instance, directory but a symbolic link.  Also used
                         if the final component of the OPEN path is a
                         symbolic link.

   NFS4ERR_TOOSMALL      Buffer or request is too small.

   NFS4ERR_WRONGSEC      The security mechanism being used by the client needs to lookup a directory entry
                         for the operation does not match the server's
                         security policy.  The client should change the
                         security mechanism being used and obtain
     its filehandle then retry the following request is needed.

             PUTFH  (directory filehandle)
             LOOKUP (entry name)
             GETFH

   ERRORS

     NFS4ERR_BADHANDLE
     NFS4ERR_FHEXPIRED
     NFS4ERR_MOVED
                         operation.

   NFS4ERR_XDEV          Attempt to do an operation between different
                         fsids.

Draft Specification      NFS version 4 Protocol                July              August 2002

     NFS4ERR_NOFILEHANDLE
     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE
     NFS4ERR_WRONGSEC

Draft Specification

13.  NFS version 4 Protocol                July 2002

14.2.9.  Operation 11: LINK - Create Link to Requests

   For the NFS version 4 RPC program, there are two traditional RPC
   procedures: NULL and COMPOUND.  All other functionality is defined as
   a File

   SYNOPSIS

     (sfh), (cfh), newname -> (cfh), change_info

   ARGUMENT

     struct LINK4args {
             /* SAVED_FH: source object */
             /* CURRENT_FH: target directory */
             component4      newname;
     };

   RESULT

     struct LINK4resok {
             change_info4    cinfo;
     };

     union LINK4res switch (nfsstat4 status) {
      case NFS4_OK:
              LINK4resok resok4;
      default:
              void;
     };

   DESCRIPTION

     The LINK operation creates an additional newname for the file
     represented by the saved filehandle, as set by the SAVEFH
     operation, of operations and these operations are defined in the directory represented by the current filehandle.
     The existing file normal
   XDR/RPC syntax and the target directory must reside semantics.  However, these operations are
   encapsulated within the
     same file system on COMPOUND procedure.  This requires that the server.  On success,
   client combine one or more of the current filehandle
     will continue NFS version 4 operations into a
   single request.

   The NFS4_CALLBACK program is used to be the target directory.  If an object exists provide server to client
   signaling and is constructed in a similar fashion as the target directory with NFS version
   4 program.  The procedures CB_NULL and CB_COMPOUND are defined in the
   same name way as newname, the server must
     return NFS4ERR_EXIST.

     For the target directory, NULL and COMPOUND are within the server returns change_info4
     information in cinfo.  With NFS program.  The
   CB_COMPOUND request also encapsulates the atomic field remaining operations of the change_info4
     struct, the server will indicate if
   NFS4_CALLBACK program.  There is no predefined RPC program number for
   the before and after change
     attributes were obtained atomically with respect NFS4_CALLBACK program.  It is up to the link
     creation.

     If the newname has client to specify a length of 0 (zero), or if newname does not
     obey the UTF-8 definition,
   program number in the error NFS4ERR_INVAL will be
     returned.

Draft Specification      NFS version 4 Protocol                July 2002

   IMPLEMENTATION

     Changes to any property "transient" program range.  The program and
   port number of the "hard" linked files NFS4_CALLBACK program are reflected in
     all provided by the client
   as part of the linked files.  When a link SETCLIENTID/SETCLIENTID_CONFIRM sequence. The program
   and port can be changed by another SETCLIENTID/SETCLIENTID_CONFIRM
   sequence, and it is made possible to use the sequence to change them
   within a file, client incarnation without removing relevant leased client
   state.

13.1.  Compound Procedure

   The COMPOUND procedure provides the
     attributes opportunity for the file should have better
   performance within high latency networks.  The client can avoid
   cumulative latency of multiple RPCs by combining multiple dependent
   operations into a value single COMPOUND procedure.  A compound operation
   may provide for numlinks protocol simplification by allowing the client to
   combine basic procedures into a single request that is
     one greater than the value before customized for
   the LINK operation. client's environment.

   The statement "file and the target directory must reside within CB_COMPOUND procedure precisely parallels the
     same file system on features of
   COMPOUND as described above.

   The basic structure of the server" means that COMPOUND procedure is:

   +-----+--------------+--------+-----------+-----------+-----------+--
   | tag | minorversion | numops | op + args | op + args | op + args |
   +-----+--------------+--------+-----------+-----------+-----------+--

   and the fsid fields reply's structure is:

          +------------+-----+--------+-----------------------+--
          |last status | tag | numres | status + op + results |
          +------------+-----+--------+-----------------------+--

   The numops and numres fields, used in the
     attributes for depiction above, represent

Draft Specification      NFS version 4 Protocol              August 2002

   the objects are count for the same. If they reside on
     different file systems, counted array encoding use to signify the error, NFS4ERR_XDEV, is returned.  On
     some servers, number of
   arguments or results encoded in the filenames, "." request and "..", are illegal as newname.

     In the case that newname is already linked to the file represented
     by response.  As per the saved filehandle,
   XDR encoding, these counts must match exactly the number of operation
   arguments or results encoded.

13.2.  Evaluation of a Compound Request

   The server will return NFS4ERR_EXIST.

     Note that symbolic links are created with process the CREATE operation.

   ERRORS

     NFS4ERR_ACCESS
     NFS4ERR_BADHANDLE
     NFS4ERR_BADXDR
     NFS4ERR_DELAY
     NFS4ERR_DQUOT
     NFS4ERR_EXIST
     NFS4ERR_FHEXPIRED
     NFS4ERR_INVAL
     NFS4ERR_IO
     NFS4ERR_ISDIR
     NFS4ERR_MLINK
     NFS4ERR_MOVED
     NFS4ERR_NAMETOOLONG
     NFS4ERR_NOENT
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_NOSPC
     NFS4ERR_NOTDIR
     NFS4ERR_NOTSUPP
     NFS4ERR_RESOURCE
     NFS4ERR_ROFS
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE
     NFS4ERR_WRONGSEC
     NFS4ERR_XDEV

Draft Specification      NFS version 4 Protocol                July 2002

14.2.10.  Operation 12: LOCK - Create Lock

   SYNOPSIS

     (cfh) locktype, reclaim, offset, length, locker -> stateid

   ARGUMENT

     struct open_to_lock_owner4 {
             seqid4          open_seqid;
             stateid4        open_stateid;
             seqid4          lock_seqid;
             lock_owner4     lock_owner;
     };

     struct exist_lock_owner4 {
             stateid4        lock_stateid;
             seqid4          lock_seqid;
     };

     union locker4 switch (bool new_lock_owner) {
      case TRUE:
             open_to_lock_owner4     open_owner;
      case FALSE:
             exist_lock_owner4       lock_owner;
     };

     enum nfs4_lock_type {
             READ_LT         = 1,
             WRITE_LT        = 2,
             READW_LT        = 3,    /* blocking read */
             WRITEW_LT       = 4     /* blocking write */
     };

     struct LOCK4args {
             /* CURRENT_FH: file */
             nfs_lock_type4  locktype;
             bool            reclaim;
             offset4         offset;
             length4         length;
             locker4         locker;
     };

   RESULT

     struct LOCK4denied {
             offset4         offset;
             length4         length;
             nfs_lock_type4  locktype;

Draft Specification      NFS version 4 Protocol                July 2002

             lock_owner4     owner;
     };

     struct LOCK4resok {
             stateid4        lock_stateid;
     };

     union LOCK4res switch (nfsstat4 status) {
      case NFS4_OK:
              LOCK4resok     resok4;
      case NFS4ERR_DENIED:
              LOCK4denied    denied;
      default:
              void;
     };

   DESCRIPTION

     The LOCK COMPOUND procedure by evaluating each of
   the operations within the COMPOUND procedure in order.  Each
   component operation requests consists of a record lock for the byte range
     specified 32 bit operation code, followed by
   the offset and argument of length parameters.  The lock determined by the type is
     also specified to be one of operation. The
   results of each operation are encoded in sequence into a reply
   buffer.  The results of each operation are preceded by the nfs4_lock_types. opcode and
   a status code (normally zero).  If this is an operation results in a
     reclaim request, non-zero
   status code, the reclaim parameter status will be TRUE;

     Bytes in a file may be locked even if those bytes are not currently
     allocated to encoded and evaluation of the file.  To lock
   compound sequence will halt and the file from a specific offset
     through reply will be returned.  Note
   that evaluation stops even in the end-of-file (no matter how long event of "non error" conditions
   such as NFS4ERR_SAME.

   There are no atomicity requirements for the file actually is)
     use a length field with all bits set to 1 (one).  To lock operations contained
   within the
     entire file, use an offset COMPOUND procedure.  The operations being evaluated as
   part of 0 (zero) and a length with all bits
     set to 1.  A length of 0 is reserved and should not COMPOUND request may be used.

     In the case evaluated simultaneously with other
   COMPOUND requests that the lock server receives.

   It is denied, the owner, offset, client's responsibility for recovering from any partially
   completed COMPOUND procedure.  Partially completed COMPOUND
   procedures may occur at any point due to errors such as
   NFS4ERR_RESOURCE and length NFS4ERR_DELAY.  This may occur even given an
   otherwise valid operation string.  Further, a server reboot which
   occurs in the middle of processing a conflicting lock are returned.

     On success, COMPOUND procedure may leave the current filehandle retains its value.

   IMPLEMENTATION

     If
   client with the server is unable to determine difficult task of determining how far COMPOUND
   processing has proceeded.  Therefore, the exact offset and length client should avoid overly
   complex COMPOUND procedures in the event of the conflicting lock, failure of an
   operation within the same offset procedure.

   Each operation assumes a "current" and length "saved" filehandle that were provided
     in is
   available as part of the arguments should be returned in execution context of the denied results. compound request.
   Operations may set, change, or return the current filehandle.  The
     File Locking section contains a full description
   "saved" filehandle is used for temporary storage of this a filehandle
   value and as operands for the
     other file locking RENAME and LINK operations.

   ERRORS

     NFS4ERR_ACCESS
     NFS4ERR_BADHANDLE
     NFS4ERR_BAD_SEQID
     NFS4ERR_BAD_STATEID

Draft Specification

13.3.  Synchronous Modifying Operations

   NFS version 4 Protocol                July 2002

     NFS4ERR_BADXDR
     NFS4ERR_DELAY
     NFS4ERR_DENIED
     NFS4ERR_EXPIRED
     NFS4ERR_FHEXPIRED
     NFS4ERR_GRACE
     NFS4ERR_INVAL
     NFS4ERR_ISDIR
     NFS4ERR_LEASE_MOVED
     NFS4ERR_LOCK_RANGE
     NFS4ERR_MOVED
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_NO_GRACE
     NFS4ERR_OLD_STATEID
     NFS4ERR_RECLAIM_BAD
     NFS4ERR_RECLAIM_CONFLICT
     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE
     NFS4ERR_STALE_CLIENTID
     NFS4ERR_STALE_STATEID
     NFS4ERR_WRONGSEC operations that modify the filesystem are synchronous.
   When an operation is successfully completed at the server, the client
   can depend that any data associated with the request is now on stable
   storage (the one exception is in the case of the file data in a WRITE
   operation with the UNSTABLE option specified).

   This implies that any previous operations within the same compound

Draft Specification      NFS version 4 Protocol                July              August 2002

14.2.11.  Operation 13: LOCKT - Test For Lock

   SYNOPSIS

     (cfh) type, owner, offset, length -> {void, NFS4ERR_DENIED ->
     owner}

   ARGUMENT

     struct LOCKT4args {
             /* CURRENT_FH: file */
             nfs_lock_type4  locktype;
             nfs_lockowner4  owner;
             offset4         offset;
             length4         length;
     };

   RESULT

     struct LOCK4denied {
             nfs_lockowner4  owner;
             offset4         offset;
             length4         length;
             nfs_lock_type4  locktype;
     };

     union LOCKT4res switch (nfsstat4 status) {
      case NFS4ERR_DENIED:
              LOCK4denied    denied;
      case NFS4_OK:
              void;
      default:
              void;
     };

   DESCRIPTION

     The LOCKT operation tests the lock as specified

   request are also reflected in stable storage.  This behavior enables
   the arguments.
     If client's ability to recover from a conflicting lock exists, partially executed compound
   request which may resulted from the owner, offset, length, and type failure of the conflicting lock are returned; server.  For
   example, if no lock is held, nothing
     other than NFS4_OK is returned.

     On success, the current filehandle retains its value.

   IMPLEMENTATION

     If a compound request contains operations A and B and the
   server is unable to determine send a response to the exact offset and length of

Draft Specification      NFS version 4 Protocol                July 2002 client, depending on the conflicting lock,
   progress the same offset and length that were provided server made in servicing the arguments should request the result of both
   operations may be returned reflected in the denied results. stable storage or just operation A may
   be reflected.  The
     File Locking section contains further discussion of server must not have just the file
     locking mechanisms.

     LOCKT uses nfs_lockowner4 instead results of a stateid4, as LOCK does, to
     identify operation
   B in stable storage.

13.4.  Operation Values

   The operations encoded in the owner so that COMPOUND procedure are identified by
   operation values.  To avoid overlap with the client does RPC procedure numbers,
   operations 0 (zero) and 1 are not have to open the
     file to test defined.  Operation 2 is not
   defined but reserved for the existence of a lock.

   ERRORS

     NFS4ERR_ACCESS
     NFS4ERR_BADHANDLE
     NFS4ERR_BADXDR
     NFS4ERR_DELAY
     NFS4ERR_DENIED
     NFS4ERR_FHEXPIRED
     NFS4ERR_GRACE
     NFS4ERR_INVAL
     NFS4ERR_ISDIR
     NFS4ERR_LEASE_MOVED
     NFS4ERR_LOCK_RANGE
     NFS4ERR_MOVED
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE
     NFS4ERR_STALE_CLIENTID
     NFS4ERR_WRONGSEC future use with minor versioning.

Draft Specification      NFS version 4 Protocol                July              August 2002

14.2.12.  Operation 14: LOCKU - Unlock File

14.  NFS version 4 Procedures

14.1.  Procedure 0: NULL - No Operation

   SYNOPSIS

     (cfh) type, seqid, stateid, offset, length -> stateid

     <null>

   ARGUMENT

     struct LOCKU4args {
             /* CURRENT_FH: file */
             nfs_lock_type4  locktype;
             seqid4          seqid;
             stateid4        stateid;
             offset4         offset;
             length4         length;
     };

     void;

   RESULT

     union LOCKU4res switch (nfsstat4 status) {
      case   NFS4_OK:
              stateid4       stateid;
      default:

     void;
     };

   DESCRIPTION

     The LOCKU operation unlocks the record lock specified by the
     parameters.

     On success, the current filehandle retains its value.

   IMPLEMENTATION

     The File Locking section contains a full description

     Standard NULL procedure.  Void argument, void response.  This
     procedure has no functionality associated with it.  Because of this and
     it is sometimes used to measure the other file locking procedures. overhead of processing a
     service request.  Therefore, the server should ensure that no
     unnecessary work is done in servicing this procedure.

   ERRORS

     NFS4ERR_ACCESS
     NFS4ERR_BADHANDLE
     NFS4ERR_BAD_SEQID
     NFS4ERR_BAD_STATEID
     NFS4ERR_BADXDR
     NFS4ERR_EXPIRED
     NFS4ERR_FHEXPIRED

Draft Specification      NFS version 4 Protocol                July 2002

     NFS4ERR_GRACE
     NFS4ERR_INVAL
     NFS4ERR_ISDIR
     NFS4ERR_LOCK_RANGE
     NFS4ERR_LEASE_MOVED
     NFS4ERR_MOVED
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_OLD_STATEID
     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE
     NFS4ERR_STALE_CLIENTID
     NFS4ERR_STALE_STATEID

     None.

Draft Specification      NFS version 4 Protocol                July              August 2002

14.2.13.  Operation 15: LOOKUP

14.2.  Procedure 1: COMPOUND - Lookup Filename Compound Operations

   SYNOPSIS

     (cfh), component

     compoundargs -> (cfh) compoundres

   ARGUMENT

     union nfs_argop4 switch (nfs_opnum4 argop) {
             case <OPCODE>: <argument>;
             ...
     };

     struct LOOKUP4args COMPOUND4args {
             /* CURRENT_FH: directory */
             component4      objname;
             utf8string      tag;
             uint32_t        minorversion;
             nfs_argop4      argarray<>;
     };

   RESULT

     union nfs_resop4 switch (nfs_opnum4 resop){
             case <OPCODE>: <result>;
             ...
     };

     struct LOOKUP4res COMPOUND4res {
             /* CURRENT_FH: object */
             nfsstat4        status;
             utf8string      tag;
             nfs_resop4      resarray<>;
     };

   DESCRIPTION

     This operation LOOKUPs

     The COMPOUND procedure is used to combine one or finds a file system object using the
     directory specified by the current filehandle.  LOOKUP evaluates more of the component NFS
     operations into a single RPC request.  The main NFS RPC program has
     two main procedures: NULL and if the object exists COMPOUND.  All other operations use
     the current filehandle COMPOUND procedure as a wrapper.

     The COMPOUND procedure is
     replaced with the component's filehandle.

     If the component cannot be evaluated either because it does not
     exist or because the client does not have permission used to evaluate combine individual operations
     into a single RPC request.  The server interprets each of the component, then
     operations in turn.  If an error will be returned and operation is executed by the current
     filehandle will be unchanged.

     If server and
     the component status of that operation is a zero length string or if any component does
     not obey the UTF-8 definition, NFS4_OK, then the error NFS4ERR_INVAL will be
     returned.

   IMPLEMENTATION

     If next operation in
     the client wants COMPOUND procedure is executed.  The server continues this
     process until there are no more operations to acheive the effect be executed or one of
     the operations has a multi-component
     lookup, it may construct a COMPOUND request such as (and obtain
     each filehandle): status value other than NFS4_OK.

Draft Specification      NFS version 4 Protocol                July              August 2002

             PUTFH  (directory filehandle)
             LOOKUP "pub"
             GETFH
             LOOKUP "foo"
             GETFH
             LOOKUP "bar"
             GETFH

     NFS version 4 servers depart from

     In the semantics processing of previous NFS
     versions in allowing LOOKUP requests to cross mountpoints on the
     server.  The client can detect a mountpoint crossing by comparing the fsid attribute of COMPOUND procedure, the directory with server may find
     that it does not have the fsid attribute available resources to execute any or all
     of the
     directory looked up.  If operations within the fsids are different then COMPOUND sequence.  In this case, the new
     directory is a server mountpoint.  Unix clients that detect a
     mountpoint crossing
     error NFS4ERR_RESOURCE will need to mount the server's filesystem.
     This needs to be done to maintain returned for the file object identity checking
     mechanisms common to Unix clients.

     Servers that limit NFS access to "shares" or "exported" filesystems
     should provide a pseudo-filesystem into which particular
     operation within the exported
     filesystems can be integrated, so that clients can browse COMPOUND procedure where the
     server's name space.  The clients view of a pseudo filesystem will
     be limited to paths resource
     exhaustion occurred.  This assumes that lead to exported filesystems.

     Note: all previous versions of the protocol assigned special semantics
     to operations
     within the names "." and "..".  NFS version 4 assigns no special
     semantics to these names. COMPOUND sequence have been evaluated successfully.  The LOOKUPP operator
     results for all of the evaluated operations must be used returned to
     lookup a parent directory.

     Note that this procedure does not follow symbolic links. the
     client.

     The
     client is responsible for all parsing server will generally choose between two methods of filenames including
     filenames that are modified by symbolic links encountered during decoding
     the lookup process.

     If client's request.  The first would be the current file handle supplied traditional one pass
     XDR decode.  If there is not a directory but a
     symbolic link, the an XDR decoding error NFS4ERR_SYMLINK is returned as the error.
     For all other non-directory file types, in this case, the
     RPC XDR decode error NFS4ERR_NOTDIR is would be returned.

   ERRORS

     NFS4ERR_ACCESS
     NFS4ERR_BADHANDLE
     NFS4ERR_BADXDR
     NFS4ERR_FHEXPIRED
     NFS4ERR_INVAL
     NFS4ERR_IO
     NFS4ERR_MOVED
     NFS4ERR_NAMETOOLONG
     NFS4ERR_NOENT

Draft Specification      NFS version 4 Protocol                July 2002

     NFS4ERR_NOFILEHANDLE
     NFS4ERR_NOTDIR
     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE
     NFS4ERR_SYMLINK
     NFS4ERR_WRONGSEC

Draft Specification      NFS version 4 Protocol                July 2002

14.2.14.  Operation 16: LOOKUPP - Lookup Parent Directory

   SYNOPSIS

     (cfh) -> (cfh)

   ARGUMENT

     /* CURRENT_FH: object */
     void;

   RESULT

     struct LOOKUPP4res {
             /* CURRENT_FH: directory */
             nfsstat4        status;
     };

   DESCRIPTION  The current filehandle is assumed second method would be
     to refer make an initial pass to a regular directory
     or a named attribute directory.  LOOKUPP assigns decode the filehandle for
     its parent directory basic COMPOUND request and
     then to be XDR decode the current filehandle.  If there individual operations; the most interesting
     is no
     parent directory the decode of attributes.  In this case, the server may
     encounter an NFS4ERR_NOENT XDR decode error must be returned.
     Therefore, NFS4ERR_NOENT during the second pass.  In this
     case, the server would return the error NFS4ERR_BADXDR to signify
     the decode error.

     The COMPOUND arguments contain a "minorversion" field.  The initial
     and default value for this field is 0 (zero).  This field will be returned
     used by future minor versions such that the server when client can communicate
     to the
     current filehandle server what minor version is at being requested.  If the root or top server
     receives a COMPOUND procedure with a minorversion field value that
     it does not support, the server MUST return an error of
     NFS4ERR_MINOR_VERS_MISMATCH and a zero length resultdata array.

     Contained within the server's file tree.

   IMPLEMENTATION

     As for LOOKUP, LOOKUPP will also cross mountpoints. COMPOUND results is a "status" field.  If the current filehandle
     results array length is not a directory or named attribute
     directory, non-zero, this status must be equivalent to
     the status of the last operation that was executed within the
     COMPOUND procedure.  Therefore, if an operation incurred an error NFS4ERR_NOTDIR is returned.

   ERRORS

     NFS4ERR_ACCESS
     NFS4ERR_BADHANDLE
     NFS4ERR_FHEXPIRED
     NFS4ERR_INVAL
     NFS4ERR_IO
     NFS4ERR_MOVED
     NFS4ERR_NOENT
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_NOTDIR
     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE

Draft Specification      NFS version 4 Protocol                July 2002

     NFS4ERR_WRONGSEC

Draft Specification      NFS version 4 Protocol                July 2002

14.2.15.  Operation 17: NVERIFY - Verify Difference in Attributes

   SYNOPSIS

     (cfh), fattr -> -

   ARGUMENT

     struct NVERIFY4args {
             /* CURRENT_FH: object */
             fattr4          obj_attributes;
     };

   RESULT

     struct NVERIFY4res {
             nfsstat4        status;
     };

   DESCRIPTION

     This operation is used to prefix a sequence of operations to be
     performed if one or more attributes have changed on some filesystem
     object.  If all the attributes match
     then the error NFS4ERR_SAME
     must "status" value will be returned.

     On success, the current filehandle retains its value.

   IMPLEMENTATION

     This same error value as is being
     returned for the operation that failed.

     Note that operations, 0 (zero) and 1 (one) are not defined for the
     COMPOUND procedure.  Operation 2 is useful as a cache validation operator. not defined but reserved for
     future definition and use with minor versioning.  If the
     object to which server
     receives a operation array that contains operation 2 and the attributes belong
     minorversion field has changed then the
     following operations may obtain new data associated with that
     object.  For instance, to check if a file has been changed and
     obtain new data if it has:

             PUTFH  (public)
             LOOKUP "pub" "foo" "bar"
             NVERIFY attrbits attrs
             READ value of 0 32767

     In (zero), an error of
     NFS4ERR_OP_ILLEGAL, as described in the case that a recommended attribute next paragraph, is specified in returned
     to the
     NVERIFY client.  If an operation array contains an operation 2 and
     the minorversion field is non-zero and the server does not support that attribute
     for
     the file system object, minor version, the server returns an error NFS4ERR_NOTSUPP of
     NFS4ERR_MINOR_VERS_MISMATCH.  Therefore, the
     NFS4ERR_MINOR_VERS_MISMATCH error takes precedence over all other
     errors.

     It is returned
     to possible that the client. server receives a request that contains an
     operation that is less than the first legal operation (OP_ACCESS)
     or greater than the last legal operation (OP_RELEASE_LOCKOWNER).

Draft Specification      NFS version 4 Protocol                July              August 2002

   ERRORS

     NFS4ERR_ACCESS
     NFS4ERR_ATTRNOTSUPP
     NFS4ERR_BADHANDLE
     NFS4ERR_BADXDR
     NFS4ERR_DELAY
     NFS4ERR_FHEXPIRED
     NFS4ERR_INVAL
     NFS4ERR_IO
     NFS4ERR_MOVED
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_NOTSUPP

     In this case, the server's response will encode the opcode
     OP_ILLEGAL rather than the illegal opcode of the request. The
     status field in the ILLEGAL return results will set to
     NFS4ERR_OP_ILLEGAL.  The COMPOUND procedure's return results will
     also be NFS4ERR_OP_ILLEGAL.

     The definition of the "tag" in the request is left to the
     implementor.  It may be used to summarize the content of the
     compound request for the benefit of packet sniffers and engineers
     debugging implementations.  However, the value of "tag" in the
     response SHOULD be the same value as provided in the request.  This
     applies to the tag field of the CB_COMPOUND procedure as well.

   IMPLEMENTATION

     Since an error of any type may occur after only a portion of the
     operations have been evaluated, the client must be prepared to
     recover from any failure.  If the source of an NFS4ERR_RESOURCE
     NFS4ERR_SAME
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE
     NFS4ERR_WRONGSEC
     error was a complex or lengthy set of operations, it is likely that
     if the number of operations were reduced the server would be able
     to evaluate them successfully.  Therefore, the client is
     responsible for dealing with this type of complexity in recovery.

   ERRORS

     All errors defined in the protocol

Draft Specification      NFS version 4 Protocol                July              August 2002

14.2.16.

14.2.1.  Operation 18: OPEN 3: ACCESS - Open a Regular File Check Access Rights

   SYNOPSIS

     (cfh), claim, openhow, owner, seqid, access, deny accessreq -> (cfh),
     stateid, cinfo, rflags, open_confirm, attrset delegation supported, accessrights

   ARGUMENT

     struct OPEN4args {
             open_claim4     claim;
             openflag4       openhow;
             nfs_lockowner4  owner;
             seqid4          seqid;
             uint32_t        share_access;
             uint32_t        share_deny;
     };

     enum createmode4 {
             UNCHECKED4      = 0,
             GUARDED4

     const ACCESS4_READ      = 1,
             EXCLUSIVE4 0x00000001;
     const ACCESS4_LOOKUP    = 2
     };

     union createhow4 switch (createmode4 mode) {
      case UNCHECKED4:
      case GUARDED4:
              fattr4         createattrs;
      case EXCLUSIVE4:
              verifier4      createverf;
     };

     enum opentype4 {
             OPEN4_NOCREATE 0x00000002;
     const ACCESS4_MODIFY    = 0,
             OPEN4_CREATE 0x00000004;
     const ACCESS4_EXTEND    = 1
     };

     union openflag4 switch (opentype4 opentype) {
      case OPEN4_CREATE:
              createhow4     how;
      default:
              void;
     };

     /* Next definitions used for OPEN delegation */
     enum limit_by4 {
             NFS_LIMIT_SIZE 0x00000008;
     const ACCESS4_DELETE    = 1,
             NFS_LIMIT_BLOCKS 0x00000010;
     const ACCESS4_EXECUTE   = 2 0x00000020;

     struct ACCESS4args {
             /* others as needed CURRENT_FH: object */
             uint32_t        access;
     };

Draft Specification      NFS version 4 Protocol                July 2002

   RESULT

     struct nfs_modified_limit4 ACCESS4resok {
             uint32_t        num_blocks;        supported;
             uint32_t        bytes_per_block;        access;
     };

     union nfs_space_limit4 ACCESS4res switch (limit_by4 limitby) (nfsstat4 status) {
      /* limit specified
      case NFS4_OK:
              ACCESS4resok   resok4;
      default:
              void;
     };

   DESCRIPTION

     ACCESS determines the access rights that a user, as identified by
     the credentials in the RPC request, has with respect to the file size */
      case NFS_LIMIT_SIZE:
              uint64_t               filesize;
      /* limit
     system object specified by number the current filehandle.  The client
     encodes the set of blocks */
      case NFS_LIMIT_BLOCKS:
              nfs_modified_limit4    mod_blocks;
     } ;

     enum open_delegation_type4 {
             OPEN_DELEGATE_NONE      = 0,
             OPEN_DELEGATE_READ      = 1,
             OPEN_DELEGATE_WRITE     = 2
     };

     enum open_claim_type4 {
             CLAIM_NULL              = 0,
             CLAIM_PREVIOUS          = 1,
             CLAIM_DELEGATE_CUR      = 2,
             CLAIM_DELEGATE_PREV     = 3
     };

     struct open_claim_delegate_cur4 {
             stateid4        delegate_stateid;
             component4      file;
     };

     union open_claim4 switch (open_claim_type4 claim) {
      /*
       * No special access rights that are to file. Ordinary OPEN be checked in the bit
     mask "access".  The server checks the permissions encoded in the
     bit mask.  If a status of NFS4_OK is returned, two bit masks are
     included in the specified file.
       */
      case CLAIM_NULL:
              /* CURRENT_FH: directory */
              component4     file;

      /*
       * Right response.  The first, "supported", represents the
     access rights for which the server can verify reliably.  The
     second, "access", represents the access rights available to the file established by
     user for the filehandle provided.  On success, the current
     filehandle retains its value.

Draft Specification      NFS version 4 Protocol              August 2002

     Note that the supported field will contain only as many values as
     was originally sent in the arguments.  For example, if the client
     sends an open previous to ACCESS operation with only the ACCESS4_READ value set and
     the server
       * reboot.  File identified by filehandle obtained at supports this value, the server will return only
     ACCESS4_READ even if it could have reliably checked other values.

     The results of this operation are necessarily advisory in nature.
     A return status of NFS4_OK and the appropriate bit set in the bit
     mask does not imply that time
       * rather than such access will be allowed to the file
     system object in the future. This is because access rights can be
     revoked by name.
       */
      case CLAIM_PREVIOUS:
              /* CURRENT_FH: the server at any time.

     The following access permissions may be requested:

   ACCESS4_READ    Read data from file being reclaimed */
              open_delegation_type4   delegate_type;

      /*
       * Right to or read a directory.

   ACCESS4_LOOKUP  Look up a name in a directory (no meaning for non-
                   directory objects).

   ACCESS4_MODIFY  Rewrite existing file based data or modify existing
                   directory entries.

   ACCESS4_EXTEND  Write new data or add directory entries.

   ACCESS4_DELETE  Delete an existing directory entry (no meaning for
                   non-directory objects).

   ACCESS4_EXECUTE Execute file (no meaning for a directory).

   On success, the current filehandle retains its value.

   IMPLEMENTATION

     In general, it is not sufficient for the client to attempt to
     deduce access permissions by inspecting the uid, gid, and mode
     fields in the file attributes or by attempting to interpret the
     contents of the ACL attribute.  This is because the server may
     perform uid or gid mapping or enforce additional access control
     restrictions.  It is also possible that the server may not be in
     the same ID space as the client.  In these cases (and perhaps
     others), the client can not reliably perform an access check with
     only current file attributes.

     In the NFS version 2 protocol, the only reliable way to determine
     whether an operation was allowed was to try it and see if it
     succeeded or failed.  Using the ACCESS operation in the NFS version
     4 protocol, the client can ask the server to indicate whether or
     not one or more classes of operations are permitted.  The ACCESS
     operation is provided to allow clients to check before doing a
     series of operations which will result in an access failure.  The
     OPEN operation provides a point where the server can verify access

Draft Specification      NFS version 4 Protocol              August 2002

     to the file object and method to return that information to the
     client.  The ACCESS operation is still useful for directory
     operations or for use in the case the UNIX API "access" is used on
     the client.

     The information returned by the server in response to an ACCESS
     call is not permanent.  It was correct at the exact time that the
     server performed the checks, but not necessarily afterwards.  The
     server can revoke access permission at any time.

     The client should use the effective credentials of the user to
     build the authentication information in the ACCESS request used to
     determine access rights.  It is the effective user and group
     credentials that are used in subsequent read and write operations.

     Many implementations do not directly support the ACCESS4_DELETE
     permission.  Operating systems like UNIX will ignore the
     ACCESS4_DELETE bit if set on an access request on a non-directory
     object.  In these systems, delete permission on a file is
     determined by the access permissions on the directory in which the
     file resides, instead of being determined by the permissions of the
     file itself.  Therefore, the mask returned enumerating which access
     rights can be determined will have the ACCESS4_DELETE value set to
     0.  This indicates to the client that the server was unable to
     check that particular access right.  The ACCESS4_DELETE bit in the
     access mask returned will then be ignored by the client.

   ERRORS

     NFS4ERR_ACCESS
     NFS4ERR_BADHANDLE
     NFS4ERR_BADXDR
     NFS4ERR_DELAY
     NFS4ERR_FHEXPIRED
     NFS4ERR_IO
     NFS4ERR_MOVED
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE

Draft Specification      NFS version 4 Protocol              August 2002

14.2.2.  Operation 4: CLOSE - Close File

   SYNOPSIS

     (cfh), seqid, open_stateid -> open_stateid

   ARGUMENT

     struct CLOSE4args {
             /* CURRENT_FH: object */
             seqid4          seqid
             stateid4        open_stateid;
     };

   RESULT

     union CLOSE4res switch (nfsstat4 status) {
      case NFS4_OK:
              stateid4       open_stateid;
      default:
              void;
     };

   DESCRIPTION

     The CLOSE operation releases share reservations for the regular or
     named attribute file as specified by the current filehandle.  The
     share reservations and other state information released at the
     server as a result of this CLOSE is only associated with the
     supplied stateid.  The sequence id provides for the correct
     ordering. State associated with other OPENs is not affected.

     If record locks are held, the client SHOULD release all locks
     before issuing a CLOSE.  The server MAY free all outstanding locks
     on CLOSE but some servers may not support the CLOSE of a file that
     still has record locks held.  The server MUST return failure if any
     locks would exist after the CLOSE.

     On success, the current filehandle retains its value.

   IMPLEMENTATION

     Even though CLOSE returns a stateid, this stateid is not useful to
     the client and should be treated as deprecated.  CLOSE "shuts down"
     the state associated with all OPENs for the file by a single

Draft Specification      NFS version 4 Protocol              August 2002

     open_owner.  As noted above, CLOSE will either release all file
     locking state or return an error.  Therefore, the stateid returned
     by CLOSE is not useful for operations that follow.

   ERRORS

     NFS4ERR_BADHANDLE
     NFS4ERR_BAD_SEQID
     NFS4ERR_BAD_STATEID
     NFS4ERR_BADXDR
     NFS4ERR_DELAY
     NFS4ERR_EXPIRED
     NFS4ERR_FHEXPIRED
     NFS4ERR_GRACE
     NFS4ERR_INVAL
     NFS4ERR_ISDIR
     NFS4ERR_LEASE_MOVED
     NFS4ERR_LOCKS_HELD
     NFS4ERR_MOVED
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_OLD_STATEID
     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE
     NFS4ERR_STALE_STATEID

Draft Specification      NFS version 4 Protocol              August 2002

14.2.3.  Operation 5: COMMIT - Commit Cached Data

   SYNOPSIS

     (cfh), offset, count -> verifier

   ARGUMENT

     struct COMMIT4args {
             /* CURRENT_FH: file */
             offset4         offset;
             count4          count;
     };

   RESULT

     struct COMMIT4resok {
             verifier4       writeverf;
     };

     union COMMIT4res switch (nfsstat4 status) {
      case NFS4_OK:
              COMMIT4resok   resok4;
      default:
              void;
     };

   DESCRIPTION

     The COMMIT operation forces or flushes data to stable storage for
     the file specified by the current filehandle.  The flushed data is
     that which was previously written with a WRITE operation which had
     the stable field set to UNSTABLE4.

     The offset specifies the position within the file where the flush
     is to begin.  An offset value of 0 (zero) means to flush data
     starting at the beginning of the file.  The count specifies the
     number of bytes of data to flush.  If count is 0 (zero), a flush
     from offset to the end of the file is done.

     The server returns a write verifier upon successful completion of
     the COMMIT.  The write verifier is used by the client to determine
     if the server has restarted or rebooted between the initial
     WRITE(s) and the COMMIT.  The client does this by comparing the
     write verifier returned from the initial writes and the verifier
     returned by the COMMIT operation.  The server must vary the value
     of the write verifier at each server event or instantiation that
     may lead to a loss of uncommitted data.  Most commonly this occurs
     when the server is rebooted; however, other events at the server

Draft Specification      NFS version 4 Protocol              August 2002

     may result in uncommitted data loss as well.

     On success, the current filehandle retains its value.

   IMPLEMENTATION

     The COMMIT operation is similar in operation and semantics to the
     POSIX fsync(2) system call that synchronizes a file's state with
     the disk (file data and metadata is flushed to disk or stable
     storage). COMMIT performs the same operation for a client, flushing
     any unsynchronized data and metadata on the server to the server's
     disk or stable storage for the specified file.  Like fsync(2), it
     may be that there is some modified data or no modified data to
     synchronize.  The data may have been synchronized by the server's
     normal periodic buffer synchronization activity.  COMMIT should
     return NFS4_OK, unless there has been an unexpected error.

     COMMIT differs from fsync(2) in that it is possible for the client
     to flush a range of the file (most likely triggered by a buffer-
     reclamation scheme on the client before file has been completely
     written).

     The server implementation of COMMIT is reasonably simple.  If the
     server receives a full file COMMIT request, that is starting at
     offset 0 and count 0, it should do the equivalent of fsync()'ing
     the file.  Otherwise, it should arrange to have the cached data in
     the range specified by offset and count to be flushed to stable
     storage.  In both cases, any metadata associated with the file must
     be flushed to stable storage before returning.  It is not an error
     for there to be nothing to flush on the server.  This means that
     the data and metadata that needed to be flushed have already been
     flushed or lost during the last server failure.

     The client implementation of COMMIT is a little more complex.
     There are two reasons for wanting to commit a client buffer to
     stable storage.  The first is that the client wants to reuse a
     buffer.  In this case, the offset and count of the buffer are sent
     to the server in the COMMIT request.  The server then flushes any
     cached data based on the offset and count, and flushes any metadata
     associated with the file.  It then returns the status of the flush
     and the write verifier.  The other reason for the client to
     generate a COMMIT is for a full file flush, such as may be done at
     close.  In this case, the client would gather all of the buffers
     for this file that contain uncommitted data, do the COMMIT
     operation with an offset of 0 and count of 0, and then free all of
     those buffers.  Any other dirty buffers would be sent to the server
     in the normal fashion.

     After a buffer is written by the client with the stable parameter
     set to UNSTABLE4, the buffer must be considered as modified by the
     client until the buffer has either been flushed via a COMMIT

Draft Specification      NFS version 4 Protocol              August 2002

     operation or written via a WRITE operation with stable parameter
     set to FILE_SYNC4 or DATA_SYNC4. This is done to prevent the buffer
     from being freed and reused before the data can be flushed to
     stable storage on the server.

     When a response is returned from either a WRITE or a COMMIT
     operation and it contains a write verifier that is different than
     previously returned by the server, the client will need to
     retransmit all of the buffers containing uncommitted cached data to
     the server.  How this is to be done is up to the implementor.  If
     there is only one buffer of interest, then it should probably be
     sent back over in a WRITE request with the appropriate stable
     parameter.  If there is more than one buffer, it might be
     worthwhile retransmitting all of the buffers in WRITE requests with
     the stable parameter set to UNSTABLE4 and then retransmitting the
     COMMIT operation to flush all of the data on the server to stable
     storage.  The timing of these retransmissions is left to the
     implementor.

     The above description applies to page-cache-based systems as well
     as buffer-cache-based systems.  In those systems, the virtual
     memory system will need to be modified instead of the buffer cache.

   ERRORS

     NFS4ERR_ACCESS
     NFS4ERR_BADHANDLE
     NFS4ERR_BADXDR
     NFS4ERR_FHEXPIRED
     NFS4ERR_INVAL
     NFS4ERR_IO
     NFS4ERR_ISDIR
     NFS4ERR_MOVED
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_RESOURCE
     NFS4ERR_ROFS
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE

Draft Specification      NFS version 4 Protocol              August 2002

14.2.4.  Operation 6: CREATE - Create a Non-Regular File Object

   SYNOPSIS

     (cfh), name, type, attrs -> (cfh), change_info, attrs_set

   ARGUMENT

     union createtype4 switch (nfs_ftype4 type) {
      case NF4LNK:
              linktext4      linkdata;
      case NF4BLK:
      case NF4CHR:
              specdata4      devdata;
      case NF4SOCK:
      case NF4FIFO:
      case NF4DIR:
              void;
     };

     struct CREATE4args {
             /* CURRENT_FH: directory for creation */
             createtype4     objtype;
             component4      objname;
             fattr4          createattrs;
     };

   RESULT

     struct CREATE4resok {
             change_info4    cinfo;
             bitmap4         attrset;        /* attributes set */
     };

     union CREATE4res switch (nfsstat4 status) {
      case NFS4_OK:
              CREATE4resok resok4;
      default:
              void;
     };

   DESCRIPTION

     The CREATE operation creates a non-regular file object in a
     directory with a given name.  The OPEN operation MUST be used to
     create a regular file.

     The objname specifies the name for the new object.  The objtype
     determines the type of object to be created: directory, symlink,

Draft Specification      NFS version 4 Protocol              August 2002

     etc.

     If an object of the same name already exists in the directory, the
     server will return the error NFS4ERR_EXIST.

     For the directory where the new file object was created, the server
     returns change_info4 information in cinfo.  With the atomic field
     of the change_info4 struct, the server will indicate if the before
     and after change attributes were obtained atomically with respect
     to the file object creation.

     If the objname has a length of 0 (zero), or if objname does not
     obey the UTF-8 definition, the error NFS4ERR_INVAL will be
     returned.

     The current filehandle is replaced by that of the new object.

     The createattrs specifies the initial set of attributes for the
     object.  The set of attributes may include any writable attribute
     valid for the object type. When the operation is successful, the
     server will return to the client an attribute mask signifying which
     attributes were successfully set for the object.

     If createattrs includes neither the owner attribute nor an ACL with
     an ACE for the owner, and if the server's filesystem both supports
     and requires an owner attribute (or an owner ACE) then the server
     MUST derive the owner (or the owner ACE). This would typically be
     from the principal indicated in the RPC credentials of the call,
     but the server's operating environment or filesystem semantics may
     dictate other methods of derivation. Similarly, if createattrs
     includes neither the group attribute nor a group ACE, and if the
     server's filesystem both supports and requires the notion of a
     group attribute (or group ACE), the server MUST derive the group
     attribute (or the corresponding owner ACE) for the file. This could
     be from the RPC call's credentials, such as the group principal if
     the credentials include it (such as with AUTH_SYS), from the group
     identifier associated with the principal in the credentials (for
     e.g., POSIX systems have a passwd database that has the group
     identifier for every user identifier), inherited from directory the
     object is created in, or whatever else the server's operating
     environment or filesystem semantics dictate. This applies to the
     OPEN operation too.

     Conversely, it is possible the client will specify in createattrs
     an owner attribute or group attribute or ACL that the principal
     indicated the RPC call's credentials does not have permissions to
     create files for. The error to be returned in this instance is
     NFS4ERR_PERM. This applies to the OPEN operation too.

   IMPLEMENTATION

Draft Specification      NFS version 4 Protocol              August 2002

     If the client desires to set attribute values after the create, a
     SETATTR operation can be added to the COMPOUND request so that the
     appropriate attributes will be set.

   ERRORS

     NFS4ERR_ACCESS
     NFS4ERR_ATTRNOTSUPP
     NFS4ERR_BADCHAR
     NFS4ERR_BADHANDLE
     NFS4ERR_BADNAME
     NFS4ERR_BADOWNER
     NFS4ERR_BADTYPE
     NFS4ERR_BADXDR
     NFS4ERR_DQUOT
     NFS4ERR_EXIST
     NFS4ERR_FHEXPIRED
     NFS4ERR_INVAL
     NFS4ERR_IO
     NFS4ERR_MOVED
     NFS4ERR_NAMETOOLONG
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_NOSPC
     NFS4ERR_NOTDIR
     NFS4ERR_NOTSUPP
     NFS4ERR_RESOURCE
     NFS4ERR_ROFS
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE

Draft Specification      NFS version 4 Protocol              August 2002

14.2.5.  Operation 7: DELEGPURGE - Purge Delegations Awaiting Recovery

   SYNOPSIS

     clientid ->

   ARGUMENT

     struct DELEGPURGE4args {
             clientid4       clientid;
     };

   RESULT

     struct DELEGPURGE4res {
             nfsstat4        status;
     };

   DESCRIPTION

     Purges all of the delegations awaiting recovery for a given client.
     This is useful for clients which do not commit delegation
     information to stable storage to indicate that conflicting requests
     need not be delayed by the server awaiting recovery of delegation
     information.

     This operation should be used by clients that record delegation
     information on stable storage on the client.  In this case,
     DELEGPURGE should be issued immediately after doing delegation
     recovery on all delegations known to the client.  Doing so will
     notify the server that no additional delegations for the client
     will be recovered allowing it to free resources, and avoid delaying
     other clients who make requests that conflict with the unrecovered
     delegations.  The set of delegations known to the server and the
     client may be different.  The reason for this is that a client may
     fail after making a request which resulted in delegation but before
     it received the results and committed them to the client's stable
     storage.

     The server MAY support DELEGPURGE, but if it does not, it MUST NOT
     support CLAIM_DELEGATE_PREV.

   ERRORS

     NFS4ERR_BADXDR
     NFS4ERR_NOTSUPP
     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE_CLIENTID

Draft Specification      NFS version 4 Protocol              August 2002

14.2.6.  Operation 8: DELEGRETURN - Return Delegation

   SYNOPSIS

     (cfh), stateid ->

   ARGUMENT

     struct DELEGRETURN4args {
             /* CURRENT_FH: delegated file */
             stateid4        stateid;
     };

   RESULT

     struct DELEGRETURN4res {
             nfsstat4        status;
     };

   DESCRIPTION

     Returns the delegation represented by the current filehandle and
     stateid.

     Delegations may be returned when recalled or voluntarily (i.e.
     before the server has recalled them).  In either case the client
     must properly propagate state changed under the context of the
     delegation to the server before returning the delegation.

   ERRORS

     NFS4ERR_BAD_STATEID
     NFS4ERR_BADXDR
     NFS4ERR_EXPIRED
     NFS4ERR_OLD_STATEID
     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE_STATEID

Draft Specification      NFS version 4 Protocol              August 2002

14.2.7.  Operation 9: GETATTR - Get Attributes

   SYNOPSIS

     (cfh), attrbits -> attrbits, attrvals

   ARGUMENT

     struct GETATTR4args {
             /* CURRENT_FH: directory or file */
             bitmap4         attr_request;
     };

   RESULT

     struct GETATTR4resok {
             fattr4          obj_attributes;
     };

     union GETATTR4res switch (nfsstat4 status) {
      case NFS4_OK:
              GETATTR4resok  resok4;
      default:
              void;
     };

   DESCRIPTION

     The GETATTR operation will obtain attributes for the filesystem
     object specified by the current filehandle.  The client sets a bit
     in the bitmap argument for each attribute value that it would like
     the server to return.  The server returns an attribute bitmap that
     indicates the attribute values for which it was able to return,
     followed by the attribute values ordered lowest attribute number
     first.

     The server must return a value for each attribute that the client
     requests if the attribute is supported by the server.  If the
     server does not support an attribute or cannot approximate a useful
     value then it must not return the attribute value and must not set
     the attribute bit in the result bitmap.  The server must return an
     error if it supports an attribute but cannot obtain its value.  In
     that case no attribute values will be returned.

     All servers must support the mandatory attributes as specified in
     the section "File Attributes".

     On success, the current filehandle retains its value.

Draft Specification      NFS version 4 Protocol              August 2002

   IMPLEMENTATION

   ERRORS

     NFS4ERR_ACCESS
     NFS4ERR_BADHANDLE
     NFS4ERR_BADXDR
     NFS4ERR_DELAY
     NFS4ERR_FHEXPIRED
     NFS4ERR_INVAL
     NFS4ERR_IO
     NFS4ERR_MOVED
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE

Draft Specification      NFS version 4 Protocol              August 2002

14.2.8.  Operation 10: GETFH - Get Current Filehandle

   SYNOPSIS

     (cfh) -> filehandle

   ARGUMENT

     /* CURRENT_FH: */
     void;

   RESULT

     struct GETFH4resok {
             nfs_fh4         object;
     };

     union GETFH4res switch (nfsstat4 status) {
      case NFS4_OK:
             GETFH4resok     resok4;
      default:
             void;
     };

   DESCRIPTION

     This operation returns the current filehandle value.

     On success, the current filehandle retains its value.

   IMPLEMENTATION

     Operations that change the current filehandle like LOOKUP or CREATE
     do not automatically return the new filehandle as a result.  For
     instance, if a client needs to lookup a directory entry and obtain
     its filehandle then the following request is needed.

             PUTFH  (directory filehandle)
             LOOKUP (entry name)
             GETFH

   ERRORS

     NFS4ERR_BADHANDLE
     NFS4ERR_FHEXPIRED
     NFS4ERR_MOVED

Draft Specification      NFS version 4 Protocol              August 2002

     NFS4ERR_NOFILEHANDLE
     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE

Draft Specification      NFS version 4 Protocol              August 2002

14.2.9.  Operation 11: LINK - Create Link to a File

   SYNOPSIS

     (sfh), (cfh), newname -> (cfh), change_info

   ARGUMENT

     struct LINK4args {
             /* SAVED_FH: source object */
             /* CURRENT_FH: target directory */
             component4      newname;
     };

   RESULT

     struct LINK4resok {
             change_info4    cinfo;
     };

     union LINK4res switch (nfsstat4 status) {
      case NFS4_OK:
              LINK4resok resok4;
      default:
              void;
     };

   DESCRIPTION

     The LINK operation creates an additional newname for the file
     represented by the saved filehandle, as set by the SAVEFH
     operation, in the directory represented by the current filehandle.
     The existing file and the target directory must reside within the
     same filesystem on the server.  On success, the current filehandle
     will continue to be the target directory.  If an object exists in
     the target directory with the same name as newname, the server must
     return NFS4ERR_EXIST.

     For the target directory, the server returns change_info4
     information in cinfo.  With the atomic field of the change_info4
     struct, the server will indicate if the before and after change
     attributes were obtained atomically with respect to the link
     creation.

     If the newname has a length of 0 (zero), or if newname does not
     obey the UTF-8 definition, the error NFS4ERR_INVAL will be
     returned.

Draft Specification      NFS version 4 Protocol              August 2002

   IMPLEMENTATION

     Changes to any property of the "hard" linked files are reflected in
     all of the linked files.  When a link is made to a file, the
     attributes for the file should have a value for numlinks that is
     one greater than the value before the LINK operation.

     The statement "file and the target directory must reside within the
     same filesystem on the server" means that the fsid fields in the
     attributes for the objects are the same. If they reside on
     different filesystems, the error, NFS4ERR_XDEV, is returned.  On
     some servers, the filenames, "." and "..", are illegal as newname.

     In the case that newname is already linked to the file represented
     by the saved filehandle, the server will return NFS4ERR_EXIST.

     Note that symbolic links are created with the CREATE operation.

   ERRORS

     NFS4ERR_ACCESS
     NFS4ERR_BADCHAR
     NFS4ERR_BADHANDLE
     NFS4ERR_BADNAME
     NFS4ERR_BADXDR
     NFS4ERR_DELAY
     NFS4ERR_DQUOT
     NFS4ERR_EXIST
     NFS4ERR_FHEXPIRED
     NFS4ERR_FILE_OPEN
     NFS4ERR_INVAL
     NFS4ERR_IO
     NFS4ERR_ISDIR
     NFS4ERR_MLINK
     NFS4ERR_MOVED
     NFS4ERR_NAMETOOLONG
     NFS4ERR_NOENT
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_NOSPC
     NFS4ERR_NOTDIR
     NFS4ERR_NOTSUPP
     NFS4ERR_RESOURCE
     NFS4ERR_ROFS
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE
     NFS4ERR_WRONGSEC
     NFS4ERR_XDEV

Draft Specification      NFS version 4 Protocol              August 2002

14.2.10.  Operation 12: LOCK - Create Lock

   SYNOPSIS

     (cfh) locktype, reclaim, offset, length, locker -> stateid

   ARGUMENT

     struct open_to_lock_owner4 {
             seqid4          open_seqid;
             stateid4        open_stateid;
             seqid4          lock_seqid;
             lock_owner4     lock_owner;
     };

     struct exist_lock_owner4 {
             stateid4        lock_stateid;
             seqid4          lock_seqid;
     };

     union locker4 switch (bool new_lock_owner) {
      case TRUE:
             open_to_lock_owner4     open_owner;
      case FALSE:
             exist_lock_owner4       lock_owner;
     };

     enum nfs_lock_type4 {
             READ_LT         = 1,
             WRITE_LT        = 2,
             READW_LT        = 3,    /* blocking read */
             WRITEW_LT       = 4     /* blocking write */
     };

     struct LOCK4args {
             /* CURRENT_FH: file */
             nfs_lock_type4  locktype;
             bool            reclaim;
             offset4         offset;
             length4         length;
             locker4         locker;
     };

   RESULT

     struct LOCK4denied {
             offset4         offset;
             length4         length;
             nfs_lock_type4  locktype;

Draft Specification      NFS version 4 Protocol              August 2002

             lock_owner4     owner;
     };

     struct LOCK4resok {
             stateid4        lock_stateid;
     };

     union LOCK4res switch (nfsstat4 status) {
      case NFS4_OK:
              LOCK4resok     resok4;
      case NFS4ERR_DENIED:
              LOCK4denied    denied;
      default:
              void;
     };

   DESCRIPTION

     The LOCK operation requests a record lock for the byte range
     specified by the offset and length parameters.  The lock type is
     also specified to be one of the nfs_lock_type4s.  If this is a
     reclaim request, the reclaim parameter will be TRUE;

     Bytes in a file may be locked even if those bytes are not currently
     allocated to the file.  To lock the file from a specific offset
     through the end-of-file (no matter how long the file actually is)
     use a length field with all bits set to 1 (one).  If the length is
     zero, or if a length which is not all bits set to one is specified,
     and length when added to the offset exceeds the maximum 64-bit
     unsigned integer value, the error NFS4ERR_INVAL will result.

     Some servers may only support locking for byte offsets that fit
     within 32 bits.  If the client specifies a range that includes a
     byte beyond the last byte offset of the 32-bit range, but does not
     include the last byte offset of the 32-bit and all of the byte
     offsets beyond it, up to the end of the valid 64-bit range, such a
     32-bit server MUST return the error NFS4ERR_BAD_RANGE.

     In the case that the lock is denied, the owner, offset, and length
     of a conflicting lock are returned.

     On success, the current filehandle retains its value.

   IMPLEMENTATION

     If the server is unable to determine the exact offset and length of
     the conflicting lock, the same offset and length that were provided
     in the arguments should be returned in the denied results.  The
     File Locking section contains a full description of this and the
     other file locking operations.

Draft Specification      NFS version 4 Protocol              August 2002

     LOCK operations are subject to permission checks and to checks
     against the access type of the associated file.  However, the
     specific right and modes required for various type of locks,
     reflect the semantics of the server-exported filesystem, and are
     not specified by the protocol.  For example, Windows 2000 allows a
     write lock of a file open for READ, while a POSIX-compliant system
     does not.

     When the client makes a lock request that corresponds to a range
     that the lockowner has locked already (with the same or different
     lock type), or to a sub-region of such a range, or to a region
     which includes multiple locks already granted to that lockowner, in
     whole or in part, and the server does not support such locking
     operations (i.e. does not support POSIX locking semantics), the
     server will return the error NFS4ERR_LOCK_RANGE.  In that case, the
     client may return an error, or it may emulate the required
     operations, using only LOCK for ranges that do not include any
     bytes already locked by that lock_owner and LOCKU of locks held by
     that lock_owner (specifying an exactly-matching range and type).
     Similarly, when the client makes a lock request that amounts to
     upgrading (changing from a read lock to a write lock) or
     downgrading (changing from write lock to a read lock) an existing
     record lock, and the server does not support such a lock, the
     server will return NFS4ERR_LOCK_NOTSUPP.  Such operations may not
     perfectly reflect the required semantics in the face of conflicting
     lock requests from other clients.

   ERRORS

     NFS4ERR_ACCESS
     NFS4ERR_BADHANDLE
     NFS4ERR_BAD_RANGE
     NFS4ERR_BAD_SEQID
     NFS4ERR_BAD_STATEID
     NFS4ERR_BADXDR
     NFS4ERR_DEADLOCK
     NFS4ERR_DELAY
     NFS4ERR_DENIED
     NFS4ERR_EXPIRED
     NFS4ERR_FHEXPIRED
     NFS4ERR_GRACE
     NFS4ERR_INVAL
     NFS4ERR_ISDIR
     NFS4ERR_LEASE_MOVED
     NFS4ERR_LOCK_NOTSUPP
     NFS4ERR_LOCK_RANGE
     NFS4ERR_MOVED
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_NO_GRACE
     NFS4ERR_OLD_STATEID
     NFS4ERR_OPENMODE

Draft Specification      NFS version 4 Protocol              August 2002

     NFS4ERR_RECLAIM_BAD
     NFS4ERR_RECLAIM_CONFLICT
     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE
     NFS4ERR_STALE_CLIENTID
     NFS4ERR_STALE_STATEID

Draft Specification      NFS version 4 Protocol              August 2002

14.2.11.  Operation 13: LOCKT - Test For Lock

   SYNOPSIS

     (cfh) locktype, offset, length owner -> {void, NFS4ERR_DENIED ->
     owner}

   ARGUMENT

     struct LOCKT4args {
             /* CURRENT_FH: file */
             nfs_lock_type4  locktype;
             offset4         offset;
             length4         length;
             lock_owner4     owner;
     };

   RESULT

     struct LOCK4denied {
             offset4         offset;
             length4         length;
             nfs_lock_type4  locktype;
             lock_owner4     owner;
     };

     union LOCKT4res switch (nfsstat4 status) {
      case NFS4ERR_DENIED:
              LOCK4denied    denied;
      case NFS4_OK:
              void;
      default:
              void;
     };

   DESCRIPTION

     The LOCKT operation tests the lock as specified in the arguments.
     If a conflicting lock exists, the owner, offset, length, and type
     of the conflicting lock are returned; if no lock is held, nothing
     other than NFS4_OK is returned.  Lock types READ_LT and READW_LT
     are processed in the same way in that a conflicting lock test is
     done without regard to blocking or non-blocking.  The same is true
     for WRITE_LT and WRITEW_LT.

     The ranges are specified as for LOCK.  The NFS4ERR_INVAL and
     NFS4ERR_BAD_RANGE errors are returned under the same circumstances
     as for LOCK.

Draft Specification      NFS version 4 Protocol              August 2002

     On success, the current filehandle retains its value.

   IMPLEMENTATION

     If the server is unable to determine the exact offset and length of
     the conflicting lock, the same offset and length that were provided
     in the arguments should be returned in the denied results.  The
     File Locking section contains further discussion of the file
     locking mechanisms.

     LOCKT uses a lock_owner4 rather a stateid4, as is used in LOCK to
     identify the owner.  This is because the client does not have to
     open the file to test for the existence of a lock, so a stateid may
     not be available.

     The test for conflicting locks should exclude locks for the current
     lockowner.  Note that since such locks are not examined the
     possible existence of overlapping ranges may not affect the results
     of LOCKT.  If the server does examine locks that match the
     lockowner for the purpose of range checking, NFS4ERR_LOCK_RANGE may
     be returned..  In the event that it returns NFS4_OK, clients may do
     a LOCK and receive NFS4ERR_LOCK_RANGE on the LOCK request because
     of the flexibility provided to the server.

   ERRORS

     NFS4ERR_ACCESS
     NFS4ERR_BADHANDLE
     NFS4ERR_BAD_RANGE
     NFS4ERR_BADXDR
     NFS4ERR_DELAY
     NFS4ERR_DENIED
     NFS4ERR_FHEXPIRED
     NFS4ERR_GRACE
     NFS4ERR_INVAL
     NFS4ERR_ISDIR
     NFS4ERR_LEASE_MOVED
     NFS4ERR_LOCK_RANGE
     NFS4ERR_MOVED
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE
     NFS4ERR_STALE_CLIENTID

Draft Specification      NFS version 4 Protocol              August 2002

14.2.12.  Operation 14: LOCKU - Unlock File

   SYNOPSIS

     (cfh) type, seqid, stateid, offset, length -> stateid

   ARGUMENT

     struct LOCKU4args {
             /* CURRENT_FH: file */
             nfs_lock_type4  locktype;
             seqid4          seqid;
             stateid4        stateid;
             offset4         offset;
             length4         length;
     };

   RESULT

     union LOCKU4res switch (nfsstat4 status) {
      case   NFS4_OK:
              stateid4       stateid;
      default:
              void;
     };

   DESCRIPTION

     The LOCKU operation unlocks the record lock specified by the
     parameters. The client may set the locktype field to any value that
     is legal for the nfs_lock_type4 enumerated type, and the server
     MUST accept any legal value for locktype. Any legal value for
     locktype has no effect on the success or failure of the LOCKU
     operation.

     The ranges are specified as for LOCK.  The NFS4ERR_INVAL and
     NFS4ERR_BAD_RANGE errors are returned under the same circumstances
     as for LOCK.

     On success, the current filehandle retains its value.

   IMPLEMENTATION

     If the area to be unlocked does not correspond exactly to a lock
     actually held by the lockowner the server may return the error
     NFS4ERR_LOCK_RANGE.  This includes the case in which the area is
     not locked, where the area is a sub-range of the area locked, where
     it overlaps the area locked without matching exactly or the area

Draft Specification      NFS version 4 Protocol              August 2002

     specified includes multiple locks held by the lockowner.  In all of
     these cases, allowed by POSIX locking semantics, a client receiving
     this error, should if it desires support for such operations,
     simulate the operation using LOCKU on ranges corresponding to locks
     it actually holds, possibly followed by LOCK requests for the sub-
     ranges not being unlocked.

   ERRORS

     NFS4ERR_ACCESS
     NFS4ERR_BADHANDLE
     NFS4ERR_BAD_RANGE
     NFS4ERR_BAD_SEQID
     NFS4ERR_BAD_STATEID
     NFS4ERR_BADXDR
     NFS4ERR_EXPIRED
     NFS4ERR_FHEXPIRED
     NFS4ERR_GRACE
     NFS4ERR_INVAL
     NFS4ERR_ISDIR
     NFS4ERR_LEASE_MOVED
     NFS4ERR_LOCK_RANGE
     NFS4ERR_MOVED
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_OLD_STATEID
     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE
     NFS4ERR_STALE_CLIENTID
     NFS4ERR_STALE_STATEID

Draft Specification      NFS version 4 Protocol              August 2002

14.2.13.  Operation 15: LOOKUP - Lookup Filename

   SYNOPSIS

     (cfh), component -> (cfh)

   ARGUMENT

     struct LOOKUP4args {
             /* CURRENT_FH: directory */
             component4      objname;
     };

   RESULT

     struct LOOKUP4res {
             /* CURRENT_FH: object */
             nfsstat4        status;
     };

   DESCRIPTION

     This operation LOOKUPs or finds a filesystem object using the
     directory specified by the current filehandle.  LOOKUP evaluates
     the component and if the object exists the current filehandle is
     replaced with the component's filehandle.

     If the component cannot be evaluated either because it does not
     exist or because the client does not have permission to evaluate
     the component, then an error will be returned and the current
     filehandle will be unchanged.

     If the component is a zero length string or if any component does
     not obey the UTF-8 definition, the error NFS4ERR_INVAL will be
     returned.

   IMPLEMENTATION

     If the client wants to achieve the effect of a multi-component
     lookup, it may construct a COMPOUND request such as (and obtain
     each filehandle):

Draft Specification      NFS version 4 Protocol              August 2002

             PUTFH  (directory filehandle)
             LOOKUP "pub"
             GETFH
             LOOKUP "foo"
             GETFH
             LOOKUP "bar"
             GETFH

     NFS version 4 servers depart from the semantics of previous NFS
     versions in allowing LOOKUP requests to cross mountpoints on the
     server.  The client can detect a mountpoint crossing by comparing
     the fsid attribute of the directory with the fsid attribute of the
     directory looked up.  If the fsids are different then the new
     directory is a server mountpoint.  UNIX clients that detect a
     mountpoint crossing will need to mount the server's filesystem.
     This needs to be done to maintain the file object identity checking
     mechanisms common to UNIX clients.

     Servers that limit NFS access to "shares" or "exported" filesystems
     should provide a pseudo-filesystem into which the exported
     filesystems can be integrated, so that clients can browse the
     server's name space.  The clients view of a pseudo filesystem will
     be limited to paths that lead to exported filesystems.

     Note: previous versions of the protocol assigned special semantics
     to the names "." and "..".  NFS version 4 assigns no special
     semantics to these names.  The LOOKUPP operator must be used to
     lookup a parent directory.

     Note that this operation does not follow symbolic links.  The
     client is responsible for all parsing of filenames including
     filenames that are modified by symbolic links encountered during
     the lookup process.

     If the current filehandle supplied is not a directory but a
     symbolic link, the error NFS4ERR_SYMLINK is returned as the error.
     For all other non-directory file types, the error NFS4ERR_NOTDIR is
     returned.

   ERRORS

     NFS4ERR_ACCESS
     NFS4ERR_BADCHAR
     NFS4ERR_BADHANDLE
     NFS4ERR_BADNAME
     NFS4ERR_BADXDR
     NFS4ERR_FHEXPIRED
     NFS4ERR_INVAL
     NFS4ERR_IO
     NFS4ERR_MOVED

Draft Specification      NFS version 4 Protocol              August 2002

     NFS4ERR_NAMETOOLONG
     NFS4ERR_NOENT
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_NOTDIR
     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE
     NFS4ERR_SYMLINK
     NFS4ERR_WRONGSEC

Draft Specification      NFS version 4 Protocol              August 2002

14.2.14.  Operation 16: LOOKUPP - Lookup Parent Directory

   SYNOPSIS

     (cfh) -> (cfh)

   ARGUMENT

     /* CURRENT_FH: object */
     void;

   RESULT

     struct LOOKUPP4res {
             /* CURRENT_FH: directory */
             nfsstat4        status;
     };

   DESCRIPTION

     The current filehandle is assumed to refer to a regular directory
     or a named attribute directory.  LOOKUPP assigns the filehandle for
     its parent directory to be the current filehandle.  If there is no
     parent directory an NFS4ERR_NOENT error must be returned.
     Therefore, NFS4ERR_NOENT will be returned by the server when the
     current filehandle is at the root or top of the server's file tree.

   IMPLEMENTATION

     As for LOOKUP, LOOKUPP will also cross mountpoints.

     If the current filehandle is not a directory or named attribute
     directory, the error NFS4ERR_NOTDIR is returned.

   ERRORS

     NFS4ERR_ACCESS
     NFS4ERR_BADHANDLE
     NFS4ERR_FHEXPIRED
     NFS4ERR_INVAL
     NFS4ERR_IO
     NFS4ERR_MOVED
     NFS4ERR_NOENT
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_NOTDIR
     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE

Draft Specification      NFS version 4 Protocol              August 2002

14.2.15.  Operation 17: NVERIFY - Verify Difference in Attributes

   SYNOPSIS

     (cfh), fattr -> -

   ARGUMENT

     struct NVERIFY4args {
             /* CURRENT_FH: object */
             fattr4          obj_attributes;
     };

   RESULT

     struct NVERIFY4res {
             nfsstat4        status;
     };

   DESCRIPTION

     This operation is used to prefix a sequence of operations to be
     performed if one or more attributes have changed on some filesystem
     object.  If all the attributes match then the error NFS4ERR_SAME
     must be returned.

     On success, the current filehandle retains its value.

   IMPLEMENTATION

     This operation is useful as a cache validation operator.  If the
     object to which the attributes belong has changed then the
     following operations may obtain new data associated with that
     object.  For instance, to check if a file has been changed and
     obtain new data if it has:

             PUTFH  (public)
             LOOKUP "foobar"
             NVERIFY attrbits attrs
             READ 0 32767

     In the case that a recommended attribute is specified in the
     NVERIFY operation and the server does not support that attribute
     for the filesystem object, the error NFS4ERR_NOTSUPP is returned to
     the client.

   When the attribute rdattr_error or any write-only attribute (e.g.

Draft Specification      NFS version 4 Protocol              August 2002

   time_modify_set) is specified, the error NFS4ERR_INVAL is returned to
   the client.  If both of these conditions apply, the server is free to
   return either error.

   ERRORS

     NFS4ERR_ACCESS
     NFS4ERR_ATTRNOTSUPP
     NFS4ERR_BADCHAR
     NFS4ERR_BADHANDLE
     NFS4ERR_BADXDR
     NFS4ERR_DELAY
     NFS4ERR_FHEXPIRED
     NFS4ERR_INVAL
     NFS4ERR_IO
     NFS4ERR_MOVED
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_NOTSUPP
     NFS4ERR_RESOURCE
     NFS4ERR_SAME
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE

Draft Specification      NFS version 4 Protocol              August 2002

14.2.16.  Operation 18: OPEN - Open a Regular File

   SYNOPSIS

     (cfh), seqid, share_access, share_deny, owner, openhow, claim ->
     (cfh), stateid, cinfo, rflags, open_confirm, attrset delegation

   ARGUMENT

     struct OPEN4args {
             seqid4          seqid;
             uint32_t        share_access;
             uint32_t        share_deny;
             open_owner4     owner;
             openflag4       openhow;
             open_claim4     claim;
     };

     enum createmode4 {
             UNCHECKED4      = 0,
             GUARDED4        = 1,
             EXCLUSIVE4      = 2
     };

     union createhow4 switch (createmode4 mode) {
      case UNCHECKED4:
      case GUARDED4:
              fattr4         createattrs;
      case EXCLUSIVE4:
              verifier4      createverf;
     };

     enum opentype4 {
             OPEN4_NOCREATE  = 0,
             OPEN4_CREATE    = 1
     };

     union openflag4 switch (opentype4 opentype) {
      case OPEN4_CREATE:
              createhow4     how;
      default:
              void;
     };

     /* Next definitions used for OPEN delegation */
     enum limit_by4 {
             NFS_LIMIT_SIZE          = 1,
             NFS_LIMIT_BLOCKS        = 2
             /* others as needed */
     };

Draft Specification      NFS version 4 Protocol              August 2002

     struct nfs_modified_limit4 {
             uint32_t        num_blocks;
             uint32_t        bytes_per_block;
     };

     union nfs_space_limit4 switch (limit_by4 limitby) {
      /* limit specified as file size */
      case NFS_LIMIT_SIZE:
              uint64_t               filesize;
      /* limit specified by number of blocks */
      case NFS_LIMIT_BLOCKS:
              nfs_modified_limit4    mod_blocks;
     } ;

     enum open_delegation_type4 {
             OPEN_DELEGATE_NONE      = 0,
             OPEN_DELEGATE_READ      = 1,
             OPEN_DELEGATE_WRITE     = 2
     };

     enum open_claim_type4 {
             CLAIM_NULL              = 0,
             CLAIM_PREVIOUS          = 1,
             CLAIM_DELEGATE_CUR      = 2,
             CLAIM_DELEGATE_PREV     = 3
     };

     struct open_claim_delegate_cur4 {
             stateid4        delegate_stateid;
             component4      file;
     };

     union open_claim4 switch (open_claim_type4 claim) {
      /*
       * No special rights to file. Ordinary OPEN of the specified file.
       */
      case CLAIM_NULL:
              /* CURRENT_FH: directory */
              component4     file;

      /*
       * Right to the file established by an open previous to server
       * reboot.  File identified by filehandle obtained at that time
       * rather than by name.
       */
      case CLAIM_PREVIOUS:
              /* CURRENT_FH: file being reclaimed */
              open_delegation_type4   delegate_type;

      /*
       * Right to file based on a delegation granted by the server.
       * File is specified by name.

Draft Specification      NFS version 4 Protocol              August 2002

       */
      case CLAIM_DELEGATE_CUR:
              /* CURRENT_FH: directory */
              open_claim_delegate_cur4       delegate_cur_info;

      /* Right to file based on a delegation granted to a previous boot
       * instance of the client.  File is specified by name.
       */
      case CLAIM_DELEGATE_PREV:
              /* CURRENT_FH: directory */
              component4     file_delegate_prev;
     };

   RESULT

     struct open_read_delegation4 {
             stateid4        stateid;        /* Stateid for delegation*/
             bool            recall;         /* Pre-recalled flag for
                                                delegations obtained
                                                by reclaim
                                                (CLAIM_PREVIOUS) */
             nfsace4         permissions;    /* Defines users who don't
                                                need an ACCESS call to
                                                open for read */
     };

     struct open_write_delegation4 {
             stateid4        stateid;        /* Stateid for delegation*/
             bool            recall;         /* Pre-recalled flag for
                                                delegations obtained
                                                by reclaim
                                                (CLAIM_PREVIOUS) */
             nfs_space_limit4 space_limit;   /* Defines condition that
                                                the client must check to
                                                determine whether the
                                                file needs to be flushed
                                                to the server on close.
                                                */
             nfsace4         permissions;    /* Defines users who don't
                                                need an ACCESS call as
                                                part of a delegated
                                                open. */
     };

     union open_delegation4
     switch (open_delegation_type4 delegation_type) {
             case OPEN_DELEGATE_NONE:
                     void;
             case OPEN_DELEGATE_READ:
                     open_read_delegation4 read;

Draft Specification      NFS version 4 Protocol              August 2002

             case OPEN_DELEGATE_WRITE:
                     open_write_delegation4 write;
     };

     const OPEN4_RESULT_CONFIRM      = 0x00000002;
     const OPEN4_RESULT_LOCKTYPE_POSIX = 0x00000004;

     struct OPEN4resok {
             stateid4        stateid;        /* Stateid for open */
             change_info4    cinfo;          /* Directory Change Info */
             uint32_t        rflags;         /* Result flags */
             bitmap4         attrset;        /* attributes on create */
             open_delegation4 delegation;    /* Info on any open
                                                delegation */
     };

     union OPEN4res switch (nfsstat4 status) {
      case NFS4_OK:
             /* CURRENT_FH: opened file */
             OPEN4resok      resok4;
      default:
             void;
     };

   WARNING TO CLIENT IMPLEMENTORS

     OPEN resembles LOOKUP in that it generates a filehandle for the
     client to use.  Unlike LOOKUP though, OPEN creates server state on
     the filehandle.  In normal circumstances, the client can only
     release this state with a CLOSE operation.  CLOSE uses the current
     filehandle to determine which file to close.  Therefore the client
     MUST follow every OPEN operation with a GETFH operation in the same
     COMPOUND procedure.  This will supply the client with the
     filehandle such that CLOSE can be used appropriately.

     Simply waiting for the lease on the file to expire is insufficient
     because the server may maintain the state indefinitely as long as
     another client does not attempt to make a conflicting access to the
     same file.

   DESCRIPTION

     The OPEN operation creates and/or opens a regular file in a
     directory with the provided name.  If the file does not exist at
     the server and creation is desired, specification of the method of
     creation is provided by the openhow parameter.  The client has the
     choice of three creation methods: UNCHECKED, GUARDED, or EXCLUSIVE.

     If the current filehandle is a named attribute directory, OPEN will
     then create or open a named attribute file.  Note that exclusive

Draft Specification      NFS version 4 Protocol              August 2002

     create of a named attribute is not supported.  If the createmode is
     EXCLUSIVE4 and the current filehandle is a named attribute
     directory, the server will return EINVAL.

     UNCHECKED means that the file should be created if a file of that
     name does not exist and encountering an existing regular file of
     that name is not an error.  For this type of create, createattrs
     specifies the initial set of attributes for the file.  The set of
     attributes may include any writable attribute valid for regular
     files.  When an UNCHECKED create encounters an existing file, the
     attributes specified by createattrs are not used, except that when
     an size of zero is specified, the existing file is truncated.  If
     GUARDED is specified, the server checks for the presence of a
     duplicate object by name before performing the create.  If a
     duplicate exists, an error of NFS4ERR_EXIST is returned as the
     status.  If the object does not exist, the request is performed as
     described for UNCHECKED.  For each of these cases (UNCHECKED and
     GUARDED) where the operation is successful, the server will return
     to the client an attribute mask signifying which attributes were
     successfully set for the object.

     EXCLUSIVE specifies that the server is to follow exclusive creation
     semantics, using the verifier to ensure exclusive creation of the
     target.  The server should check for the presence of a duplicate
     object by name.  If the object does not exist, the server creates
     the object and stores the verifier with the object.  If the object
     does exist and the stored verifier matches the client provided
     verifier, the server uses the existing object as the newly created
     object.  If the stored verifier does not match, then an error of
     NFS4ERR_EXIST is returned.  No attributes may be provided in this
     case, since the server may use an attribute of the target object to
     store the verifier.  If the server uses an attribute to store the
     exclusive create verifier, it will signify which attribute by
     setting the appropriate bit in the attribute mask that is returned
     in the results.

     For the target directory, the server returns change_info4
     information in cinfo.  With the atomic field of the change_info4
     struct, the server will indicate if the before and after change
     attributes were obtained atomically with respect to the link
     creation.

     Upon successful creation, the current filehandle is replaced by
     that of the new object.

     The OPEN operation provides for Windows share reservation
     capability with the use of the access and deny fields of the OPEN
     arguments.  The client specifies at OPEN the required access and
     deny modes.  For clients that do not directly support SHAREs (i.e.
     UNIX), the expected deny value is DENY_NONE.  In the case that
     there is a existing SHARE reservation that conflicts with the OPEN
     request, the server returns the error NFS4ERR_SHARE_DENIED.  For a

Draft Specification      NFS version 4 Protocol              August 2002

     complete SHARE request, the client must provide values for the
     owner and seqid fields for the OPEN argument.  For additional
     discussion of SHARE semantics see the section on 'Share
     Reservations'.

     In the case that the client is recovering state from a server
     failure, the claim field of the OPEN argument is used to signify
     that the request is meant to reclaim state previously held.

     The "claim" field of the OPEN argument is used to specify the file
     to be opened and the state information which the client claims to
     possess.  There are four basic claim types which cover the various
     situations for an OPEN.  They are as follows:

     CLAIM_NULL
                           For the client, this is a new OPEN
                           request and there is no previous state
                           associate with the file for the client.

     CLAIM_PREVIOUS
                           The client is claiming basic OPEN state
                           for a file that was held previous to a
                           server reboot.  Generally used when a
                           server is returning persistent
                           filehandles; the client may not have the
                           file name to reclaim the OPEN.

     CLAIM_DELEGATE_CUR
                           The client is claiming a delegation for
                           OPEN as granted by the server.
                           Generally this is done as part of
                           recalling a delegation.

     CLAIM_DELEGATE_PREV
                           The client is claiming a delegation
                           granted to a previous client instance;
                           used after the client reboots. The
                           server MAY support CLAIM_DELEGATE_PREV.
                           If it does support CLAIM_DELEGATE_PREV,
                           SETCLIENTID_CONFIRM MUST NOT remove the
                           client's delegation state, and the
                           server MUST support the DELEGEPURGE
                           operation.

     For OPEN requests whose claim type is other than CLAIM_PREVIOUS
     (i.e. requests other than those devoted to reclaiming opens after a
     server reboot) that reach the server during its grace or lease
     expiration period, the server returns an error of NFS4ERR_GRACE.

     For any OPEN request, the server may return an open delegation,
     which allows further opens and closes to be handled locally on the
     client as described in the section Open Delegation.  Note that
     delegation is up to the server to decide.  The client should never
     assume that delegation will or will not be granted in a particular
     instance.  It should always be prepared for either case.  A partial

Draft Specification      NFS version 4 Protocol              August 2002

     exception is the reclaim (CLAIM_PREVIOUS) case, in which a
     delegation type is claimed.  In this case, delegation will always
     be granted, although the server may specify an immediate recall in
     the delegation structure.

     The rflags returned by a successful OPEN allow the server to return
     information governing how the open file is to be handled.
     OPEN4_RESULT_CONFIRM indicates that the client MUST execute an
     OPEN_CONFIRM operation before using the open file.
     OPEN4_RESULT_LOCKTYPE_POSIX indicates the server's file locking
     behavior is Posix like with respect to lock range coalescing.  From
     this the client can choose to manage file locking state in a way to
     handle a mis-match of file locking management.

     If the component is of zero length, NFS4ERR_INVAL will be returned.
     The component is also subject to the normal UTF-8, character
     support, and name checks.  See the section "UTF-8 Related Errors"
     for further discussion.

     When an OPEN is done and the specified lockowner already has the
     resulting filehandle open, the result is to "OR" together the new
     share and deny status together with the existing status.  In this
     case, only a single CLOSE need be done, even though multiple OPEN's
     were completed.  When such an OPEN is done, checking of share
     reservations for the new OPEN proceeds normally, with no exception
     for the existing OPEN held by the same lockowner.

     If the underlying filesystem at the server is only accessible in a
     read-only mode and the OPEN request has specified ACCESS_WRITE or
     ACCESS_BOTH, the server will return NFS4ERR_ROFS to indicate a
     read-only filesystem.

     As with the CREATE operation, the server MUST derive the owner,
     owner ACE, group, or group ACE if any of the four attributes are
     required and supported by the server's filesystem.  For an OPEN
     with the EXCLUSIVE4 createmode, the server has no choice, since
     such OPEN calls do not include the createattrs field.  Conversely,
     if createattrs is specified, and includes owner or group (or
     corresponding ACEs) that the principal in the RPC call's
     credentials does not have authorization to create files for, then
     the server may return NFS4ERR_PERM.

     In the case of a OPEN which specifies a size of zero (e.g.
     truncation) and the file has named attributes, the named attributes
     are left as is.  They are not removed.

   IMPLEMENTATION

     The OPEN operation contains support for EXCLUSIVE create.  The
     mechanism is similar to the support in NFS version 3 [RFC1813].  As
     in NFS version 3, this mechanism provides reliable exclusive

Draft Specification      NFS version 4 Protocol              August 2002

     creation.  Exclusive create is invoked when the how parameter is
     EXCLUSIVE.  In this case, the client provides a verifier that can
     reasonably be expected to be unique.  A combination of a client
     identifier, perhaps the client network address, and a unique number
     generated by the client, perhaps the RPC transaction identifier,
     may be appropriate.

     If the object does not exist, the server creates the object and
     stores the verifier in stable storage. For filesystems that do not
     provide a mechanism for the storage of arbitrary file attributes,
     the server may use one or more elements of the object meta-data to
     store the verifier. The verifier must be stored in stable storage
     to prevent erroneous failure on retransmission of the request. It
     is assumed that an exclusive create is being performed because
     exclusive semantics are critical to the application. Because of the
     expected usage, exclusive CREATE does not rely solely on the
     normally volatile duplicate request cache for storage of the
     verifier. The duplicate request cache in volatile storage does not
     survive a crash and may actually flush on a long network partition,
     opening failure windows.  In the UNIX local filesystem environment,
     the expected storage location for the verifier on creation is the
     meta-data (time stamps) of the object. For this reason, an
     exclusive object create may not include initial attributes because
     the server would have nowhere to store the verifier.

     If the server can not support these exclusive create semantics,
     possibly because of the requirement to commit the verifier to
     stable storage, it should fail the OPEN request with the error,
     NFS4ERR_NOTSUPP.

     During an exclusive CREATE request, if the object already exists,
     the server reconstructs the object's verifier and compares it with
     the verifier in the request. If they match, the server treats the
     request as a success. The request is presumed to be a duplicate of
     an earlier, successful request for which the reply was lost and
     that the server duplicate request cache mechanism did not detect.
     If the verifiers do not match, the request is rejected with the
     status, NFS4ERR_EXIST.

     Once the client has performed a successful exclusive create, it
     must issue a SETATTR to set the correct object attributes.  Until
     it does so, it should not rely upon any of the object attributes,
     since the server implementation may need to overload object meta-
     data to store the verifier.  The subsequent SETATTR must not occur
     in the same COMPOUND request as the OPEN.  This separation will
     guarantee that the exclusive create mechanism will continue to
     function properly in the face of retransmission of the request.

     Use of the GUARDED attribute does not provide exactly-once
     semantics.  In particular, if a reply is lost and the server does
     not detect the retransmission of the request, the operation can
     fail with NFS4ERR_EXIST, even though the create was performed

Draft Specification      NFS version 4 Protocol              August 2002

     successfully.  The client would use this behavior in the case that
     the application has not requested an exclusive create but has asked
     to have the file truncated when the file is opened.  In the case of
     the client timing out and retransmitting the create request, the
     client can use GUARDED to prevent against a sequence like: create,
     write, create (retransmitted) from occurring.

     For SHARE reservations, the client must specify a value for access
     that is one of READ, WRITE, or BOTH.  For deny, the client must
     specify one of NONE, READ, WRITE, or BOTH.  If the client fails to
     do this, the server must return NFS4ERR_INVAL.

     Based on the access value (READ, WRITE, or BOTH) the client should
     check that the requestor has the proper access rights to perform
     the specified operation.  This would generally be the results of
     applying the ACL access rules to the file for the current
     requestor.  However, just as with the ACCESS operation, the client
     should not attempt to second-guess the server's decisions, as
     access rights may change and may be subject to server
     administrative controls outside the ACL framework.  If the
     requestor is not authorized to READ or WRITE (depending on the
     access value), the server must return NFS4ERR_ACCESS.  Note that
     since the NFS version 4 protocol does not impose any requirement
     that READ's and WRITE's issued for an open file have the same
     credentials as the OPEN itself, the server still must do
     appropriate access checking on the READ's and WRITE's themselves.

     If the component provided to OPEN is a delegation granted by symbolic link, the server.
       * File error
     NFS4ERR_SYMLINK will be returned to the client.  If the current
     filehandle is specified by name. not a directory, the error NFS4ERR_NOTDIR will be
     returned.

   ERRORS

     NFS4ERR_ACCESS
     NFS4ERR_ATTRNOTSUPP
     NFS4ERR_BADCHAR
     NFS4ERR_BADHANDLE
     NFS4ERR_BADNAME
     NFS4ERR_BADOWNER
     NFS4ERR_BAD_SEQID
     NFS4ERR_BADXDR
     NFS4ERR_DELAY
     NFS4ERR_DQUOT
     NFS4ERR_EXIST
     NFS4ERR_EXPIRED
     NFS4ERR_FHEXPIRED
     NFS4ERR_GRACE
     NFS4ERR_IO
     NFS4ERR_ISDIR
     NFS4ERR_LEASE_MOVED

Draft Specification      NFS version 4 Protocol                July              August 2002

       */
      case CLAIM_DELEGATE_CUR:
              /* CURRENT_FH: directory */
              open_claim_delegate_cur4       delegate_cur_info;

      /* Right to file based on a delegation granted to a previous boot
       * instance of the client.  File is specified by name.
       */
      case CLAIM_DELEGATE_PREV:

     NFS4ERR_MOVED
     NFS4ERR_NAMETOOLONG
     NFS4ERR_NOENT
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_NOSPC
     NFS4ERR_NOTDIR
     NFS4ERR_NOTSUPP
     NFS4ERR_NO_GRACE
     NFS4ERR_RECLAIM_BAD
     NFS4ERR_RECLAIM_CONFLICT
     NFS4ERR_RESOURCE
     NFS4ERR_ROFS
     NFS4ERR_SERVERFAULT
     NFS4ERR_SHARE_DENIED
     NFS4ERR_STALE_CLIENTID
     NFS4ERR_SYMLINK
     NFS4ERR_WRONGSEC

Draft Specification      NFS version 4 Protocol              August 2002

14.2.17.  Operation 19: OPENATTR - Open Named Attribute Directory

   SYNOPSIS

     (cfh) createdir -> (cfh)

   ARGUMENT

     struct OPENATTR4args {
             /* CURRENT_FH: directory object */
              component4     file_delegate_prev;
             bool    createdir;
     };

   RESULT

     struct open_read_delegation4 OPENATTR4res {
             stateid4        stateid;        /* Stateid for delegation*/
             bool            recall;         /* Pre-recalled flag for
                                                delegations obtained
                                                by reclaim
                                                (CLAIM_PREVIOUS) */
             nfsace4         permissions;
             /* Defines users who don't
                                                need CURRENT_FH: named attr directory*/
             nfsstat4        status;
     };

   DESCRIPTION

     The OPENATTR operation is used to obtain the filehandle of the
     named attribute directory associated with the current filehandle.
     The result of the OPENATTR will be a filehandle to an ACCESS call object of
     type NF4ATTRDIR.  From this filehandle, READDIR and LOOKUP
     operations can be used to
                                                open for read */
     };

     struct open_write_delegation4 {
             stateid4        stateid;        /* Stateid for delegation*/
             bool            recall;         /* Pre-recalled flag obtain filehandles for
                                                delegations obtained
                                                by reclaim
                                                (CLAIM_PREVIOUS) */
             nfs_space_limit4 space_limit;   /* Defines condition that the various named
     attributes associated with the original filesystem object.
     Filehandles returned within the named attribute directory will have
     a type of NF4NAMEDATTR.

     The createdir argument allows the client must check to
                                                determine whether signify if a named
     attribute directory should be created as a result of the
                                                file needs OPENATTR
     operation.  Some clients may use the OPENATTR operation with a
     value of FALSE for createdir to determine if any named attributes
     exist for the object.  If none exist, then NFS4ERR_NOENT will be flushed
     returned.  If createdir has a value of TRUE and no named attribute
     directory exists, one is created.  The creation of a named
     attribute directory assumes that the server has implemented named
     attribute support in this fashion and is not required to do so by
     this definition.

   IMPLEMENTATION

     If the server on close.
                                                */
             nfsace4         permissions;    /* Defines users who don't
                                                need does not support named attributes for the current
     filehandle, an ACCESS call as
                                                part error of a delegated
                                                open. */
     };

     union open_delegation4
     switch (open_delegation_type4 delegation_type) {
             case OPEN_DELEGATE_NONE:
                     void;
             case OPEN_DELEGATE_READ:
                     open_read_delegation4 read; NFS4ERR_NOTSUPP will be returned to the
     client.

Draft Specification      NFS version 4 Protocol                July              August 2002

             case OPEN_DELEGATE_WRITE:
                     open_write_delegation4 write;
     };

     const OPEN4_RESULT_MLOCK        = 0x00000001;
     const OPEN4_RESULT_CONFIRM= 0x00000002;
     const OPEN4_RESULT_LOCKTYPE_POSIX = 0x00000004;

     struct OPEN4resok {
             stateid4        stateid;        /* Stateid for open */
             change_info4    cinfo;          /* Directory Change Info */
             uint32_t        rflags;         /* Result flags */
             bitmap4         attrset;        /* attributes on create */
             open_delegation4 delegation;

   ERRORS

     NFS4ERR_ACCESS
     NFS4ERR_BADHANDLE
     NFS4ERR_BADXDR
     NFS4ERR_DELAY
     NFS4ERR_FHEXPIRED
     NFS4ERR_INVAL
     NFS4ERR_IO
     NFS4ERR_MOVED
     NFS4ERR_NOENT
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_NOSPC
     NFS4ERR_NOTSUPP
     NFS4ERR_RESOURCE
     NFS4ERR_ROFS
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE
     NFS4ERR_WRONGSEC

Draft Specification      NFS version 4 Protocol              August 2002

14.2.18.  Operation 20: OPEN_CONFIRM - Confirm Open

   SYNOPSIS

     (cfh), seqid, stateid-> stateid

   ARGUMENT

     struct OPEN_CONFIRM4args {
             /* Info on any open
                                                delegation CURRENT_FH: opened file */
             seqid4          seqid;
             stateid4        stateid;
     };

   RESULT

     struct OPEN_CONFIRM4resok {
             stateid4        stateid;
     };

     union OPEN4res OPEN_CONFIRM4res switch (nfsstat4 status) {
      case NFS4_OK:
             /* CURRENT_FH: opened file */
             OPEN4resok
              OPEN_CONFIRM4resok     resok4;
      default:
              void;
     };

   WARNING TO CLIENT IMPLEMENTORS

     OPEN resembles LOOKUP in that it generates a filehandle for the
     client

   DESCRIPTION

     This operation is used to use.  Unlike LOOKUP though, OPEN creates server state on confirm the filehandle.  In normal circumstances, sequence id usage for the client can only
     release this state with
     first time that a CLOSE operation.  CLOSE uses the current
     filehandle to determine which file to close.  Therefore open_owner is used by a client.  The stateid
     returned from the client
     MUST follow every OPEN operation with a GETFH operation in the same
     COMPOUND procedure.  This will supply is used as the client argument for this
     operation along with the
     filehandle such that CLOSE can be used appropriately.

     Simply waiting next sequence id for the lease on the file open_owner.  The
     sequence id passed to expire is insufficient
     because the server may maintain OPEN_CONFIRM must be 1 (one) greater than
     the state indefinitely as long as
     another client does not attempt to make a conflicting access seqid passed to the
     same file.

   DESCRIPTION

     The OPEN operation creates and/or opens a regular file in a
     directory with from which the provided name. open_confirm
     value was obtained.  If the file does not exist at server receives an unexpected sequence
     id with respect to the original open, then the server assumes that
     the client will not confirm the original OPEN and creation is desired, specification of all state
     associated with the method of
     creation original OPEN is provided released by the openhow parameter. server.

     On success, the current filehandle retains its value.

   IMPLEMENTATION

     A given client might generate many open_owner4 data structures for
     a given clientid.  The client has the
     choice will periodically either dispose of three creation methods: UNCHECKED, GUARDED,
     its open_owner4s or EXCLUSIVE.

     UNCHECKED means that the file should be created if a file stop using them for indefinite periods of that time.
     The latter situation is why the NFS version 4 protocol does not

Draft Specification      NFS version 4 Protocol                July              August 2002

     name does not exist and encountering

     have an existing regular file of
     that name is not explicit operation to exit an error.  For this type open_owner4: such an
     operation is of create, createattrs
     specifies no use in that situation.  Instead, to avoid
     unbounded memory use, the initial set of attributes server needs to implement a strategy for the file.  The set
     disposing of
     attributes may include any writable attribute valid open_owner4s that have no current lock, open, or
     delegation state for regular
     files.  When an UNCHECKED create encounters an existing file, the
     attributes specified by createattrs is any files and have not used, except that been used recently.
     The time period used to determine when
     an size to dispose of zero is specified, the existing file open_owner4s
     is truncated.  If
     GUARDED is specified, the server checks for the presence of a
     duplicate object by name before performing the create.  If a
     duplicate exists, an error of NFS4ERR_EXIST is returned as the
     status.  If the object does not exist, implementation choice.  The time period should certainly be
     no less than the request is performed as
     described for UNCHECKED.  For each of these cases (UNCHECKED and
     GUARDED) where lease time plus any grace period the server wishes
     to implement beyond a lease time.  The OPEN_CONFIRM operation is successful,
     allows the server will return to safely dispose of unused open_owner4 data
     structures.

     In the case that a client issues an attribute mask signifying which attributes were
     successfully set for the object.

     EXCLUSIVE specifies that OPEN operation and the server is to follow exclusive creation
     semantics, using
     no longer has a record of the verifier to open_owner4, the server needs ensure exclusive creation
     that this is a new OPEN and not a replay or retransmission.

     Servers must not require confirmation on OPEN's that grant
     delegations or are doing reclaim operations.  See section "Use of the
     target.
     Open Confirmation" for details.  The server should check can easily avoid this
     by noting whether it has disposed of one open_owner4 for the presence of a duplicate
     object by name. given
     clientid.  If the object server does not exist, the support delegation, it might
     simply maintain a single bit that notes whether any open_owner4
     (for any client) has been disposed of.

     The server creates
     the object and stores must hold unconfirmed OPEN state until one of three
     events occur.  First, the verifier client sends an OPEN_CONFIRM request with
     the object.  If the object
     does exist appropriate sequence id and stateid within the stored verifier matches the client provided
     verifier, the server uses the existing object as the newly created
     object.  If the stored verifier does not match, then an error of
     NFS4ERR_EXIST is returned.  No attributes may be provided in lease period.
     In this case, since the server may use an attribute of the target object to
     store the verifier.  If OPEN state on the server uses an attribute goes to store confirmed, and
     the
     exclusive create verifier, it will signify which attribute by
     setting open_owner4 on the appropriate bit in server is fully established.

     Second, the attribute mask client sends another OPEN request with a sequence id
     that is returned
     in the results.

     For the target directory, the server returns change_info4
     information in cinfo.  With incorrect for the atomic field open_owner4 (out of the change_info4
     struct, sequence).  In this
     case, the server will indicate if assumes the before second OPEN request is valid and after change
     attributes were obtained atomically with respect to the link
     creation.

     Upon successful creation, the current filehandle
     first one is replaced by
     that of the new object. a replay.  The OPEN procedure provides for DOS SHARE capability with the use
     of server cancels the access and deny fields OPEN state of the
     first OPEN arguments.  The client
     specifies at request, establishes an unconfirmed OPEN state for the required access
     second OPEN request, and deny modes.  For clients
     that do not directly support SHAREs (i.e. Unix), the expected deny
     value is DENY_NONE.  In responds to the case second OPEN request with
     an indication that an OPEN_CONFIRM is needed.  The process then
     repeats itself.  While there is a existing SHARE
     reservation that conflicts with potential for a denial of service
     attack on the OPEN request, client, it is mitigated if the client and server
     returns
     require the error NFS4ERR_DENIED.  For use of a complete SHARE request, security flavor based on Kerberos V5, LIPKEY,
     or some other flavor that uses cryptography.

     What if the client must provide values for server is in the owner and seqid fields unconfirmed OPEN state for a given
     open_owner4, and it receives an operation on the OPEN argument.  For additional discussion of SHARE semantics
     see open_owner4 that
     has a stateid but the operation is not OPEN, or it is OPEN_CONFIRM
     but with the section on 'Share Reservations'.

     In wrong stateid?  Then, even if the case that seqid is correct,
     the client server returns NFS4ERR_BAD_STATEID, because the server assumes
     the operation is recovering state from a replay: if the server has no established OPEN
     state, then there is no way, for example, a LOCK operation could be
     valid.

     Third, neither of the two aforementioned events occur for the

Draft Specification      NFS version 4 Protocol                July              August 2002

     failure,

     open_owner4 within the reclaim field of lease period.  In this case, the OPEN argument is used to signify
     that the request is meant to reclaim state previously held.

     The "claim" field
     is cancelled and disposal of the OPEN argument open_owner4 can occur.

   ERRORS

     NFS4ERR_BADHANDLE
     NFS4ERR_BAD_SEQID
     NFS4ERR_BADXDR
     NFS4ERR_EXPIRED
     NFS4ERR_FHEXPIRED
     NFS4ERR_GRACE
     NFS4ERR_INVAL
     NFS4ERR_ISDIR
     NFS4ERR_MOVED
     NFS4ERR_NOENT
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_NOTSUPP
     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE

Draft Specification      NFS version 4 Protocol              August 2002

14.2.19.  Operation 21: OPEN_DOWNGRADE - Reduce Open File Access

   SYNOPSIS

     (cfh), stateid, seqid, access, deny -> stateid

   ARGUMENT

     struct OPEN_DOWNGRADE4args {
             /* CURRENT_FH: opened file */
             stateid4        stateid;
             seqid4          seqid;
             uint32_t        share_access;
             uint32_t        share_deny;
     };

   RESULT

     struct OPEN_DOWNGRADE4resok {
             stateid4        stateid;
     };

     union OPEN_DOWNGRADE4res switch(nfsstat4 status) {
      case NFS4_OK:
             OPEN_DOWNGRADE4resok    resok4;
      default:
             void;
     };

   DESCRIPTION

     This operation is used to specify adjust the file
     to be opened access and the state information which the client claims to
     possess.  There are four basic claim types which cover the various
     situations deny bits for an OPEN.  They are as follows:

     CLAIM_NULL
                           For a
     given open.  This is necessary when a given lockowner opens the client,
     same file multiple times with different access and deny flags.  In
     this is situation, a new OPEN
                           request close of one of the open's may change the
     appropriate access and there is no previous state
                           associate deny flags to remove bits associated with
     open's no longer in effect.

     The access and deny bits specified in this operation replace the file
     current ones for the client.

     CLAIM_PREVIOUS specified open file.  The client is claiming basic OPEN state
                           for a file that was held previous access and deny bits
     specified must be exactly equal to a
                           server reboot.  Generally used when a
                           server is returning persistent file
                           handles; the client may not have union of the
                           file name to reclaim access and deny
     bits specified for some subset of the OPEN.

     CLAIM_DELEGATE_CUR
                           The client is claiming a delegation OPEN's in effect for
                           OPEN as granted by current
     openowner on the server.
                           Generally this current file.  If that constraint is done as part not
     respected, the error NFS4ERR_INVAL should be returned.  Since
     access and deny bits are subsets of
                           recalling a delegation.

     CLAIM_DELEGATE_PREV
                           The client those already granted, it is claiming a delegation
                           granted
     not possible for this request to a previous client instance;
                           used after be denied because of conflicting
     share reservations.

     On success, the client reboots.

     For OPEN requests whose claim type is other than CLAIM_PREVIOUS
     (i.e. requests other than those devoted to reclaiming opens after a
     server reboot) that reach current filehandle retains its value.

Draft Specification      NFS version 4 Protocol              August 2002

   ERRORS

     NFS4ERR_BADHANDLE
     NFS4ERR_BAD_SEQID
     NFS4ERR_BAD_STATEID
     NFS4ERR_BADXDR
     NFS4ERR_EXPIRED
     NFS4ERR_FHEXPIRED
     NFS4ERR_INVAL
     NFS4ERR_MOVED
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_OLD_STATEID
     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE
     NFS4ERR_STALE_STATEID

Draft Specification      NFS version 4 Protocol              August 2002

14.2.20.  Operation 22: PUTFH - Set Current Filehandle

   SYNOPSIS

     filehandle -> (cfh)

   ARGUMENT

     struct PUTFH4args {
             nfs_fh4         object;
     };

   RESULT

     struct PUTFH4res {
             /* CURRENT_FH: */
             nfsstat4        status;
     };

   DESCRIPTION

     Replaces the server during its grace or lease
     expiration period, current filehandle with the server returns filehandle provided as an error of NFS4ERR_GRACE.

     For any OPEN request,
     argument.

     If the server may return an open delegation,
     which allows further opens and closes to be handled locally on security mechanism used by the
     client as described in requestor does not meet the section Open Delegation.  Note that
     delegation is up to
     requirements of the server filehandle provided to decide.  The client should never
     assume that delegation will or will not be granted in a particular
     instance.  It should always be prepared for either case.  A partial
     exception is the reclaim (CLAIM_PREVIOUS) case, in which a
     delegation type is claimed.  In this case, delegation will always
     be granted, although the server may specify an immediate recall in
     the delegation structure.

     The rflags returned by a successful OPEN allow operation, the
     server to MUST return
     information governing how the open file is to be handled.
     OPEN4_RESULT_MLOCK indicates to NFS4ERR_WRONGSEC.

   IMPLEMENTATION

     Commonly used as the caller that mandatory locking
     is first operator in effect for this file and the client should act appropriately
     with regard to data cached on the client.  OPEN4_RESULT_CONFIRM
     indicates that the client MUST execute an OPEN_CONFIRM operation
     before using NFS request to set the open file.  OPEN4_RESULT_LOCKTYPE_POSIX indicates
     context for following operations.

   ERRORS

     NFS4ERR_BADHANDLE
     NFS4ERR_BADXDR
     NFS4ERR_FHEXPIRED
     NFS4ERR_MOVED
     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE
     NFS4ERR_WRONGSEC

Draft Specification      NFS version 4 Protocol                July              August 2002

14.2.21.  Operation 23: PUTPUBFH - Set Public Filehandle

   SYNOPSIS

     - -> (cfh)

   ARGUMENT

     void;

   RESULT

     struct PUTPUBFH4res {
             /* CURRENT_FH: public fh */
             nfsstat4        status;
     };

   DESCRIPTION

     Replaces the current filehandle with the filehandle that represents
     the public filehandle of the server's file locking behavior is Posix like name space.  This filehandle
     may be different from the "root" filehandle which may be associated
     with respect to
     lock range coalescing.  From this some other directory on the client can choose to manage
     file locking state server.

     The public filehandle represents the concepts embodied in
     [RFC2054], [RFC2055], [RFC2224].  The intent for NFS version 4 is
     that the public filehandle (represented by the PUTPUBFH operation)
     be used as a way to handle a mis-match method of file locking
     management.

     If providing WebNFS server compatibility with
     NFS versions 2 and 3.

     The public filehandle and the component is of zero length or if root filehandle (represented by the component does not
     obey
     PUTROOTFH operation) should be equivalent.  If the UTF-8 definition, public and root
     filehandles are not equivalent, then the error NFS4ERR_INVAL will public filehandle MUST be
     returned.

     When
     a descendant of the root filehandle.

   IMPLEMENTATION

     Used as the first operator in an OPEN is done and NFS request to set the specified lockowner already has context for
     following operations.

     With the
     resulting filehandle open, NFS version 2 and 3 public filehandle, the result client is able
     to "OR" together specify whether the new
     share and deny status together with path name provided in the existing status.  In this
     case, only a single CLOSE need LOOKUP should be done, even though multiple OPEN's
     were completed.

     If
     evaluated as either an absolute path relative to the underlying filesystem at server's root
     or relative to the server public filehandle.  [RFC2224] contains further
     discussion of the functionality.  With NFS version 4, that type of
     specification is only accessible not directly available in a
     read-only mode and the OPEN request has specified ACCESS_WRITE or
     ACCESS_BOTH, the server will return NFS4ERR_ROFS to indicate a
     read-only filesystem.

   IMPLEMENTATION LOOKUP operation.
     The OPEN procedure contains support reason for EXCLUSIVE create.  The
     mechanism this is similar to because the support component separators needed to
     specify absolute vs. relative are not allowed in NFS version 3 [RFC1813].  As
     in 4.

Draft Specification      NFS version 3, this mechanism provides reliable exclusive
     creation.  Exclusive create is invoked when the how parameter is
     EXCLUSIVE.  In this case, 4 Protocol              August 2002

     Therefore, the client provides a verifier is responsible for constructing its request
     such that can
     reasonably be expected the use of either PUTROOTFH or PUTPUBFH are used to be unique.  A combination
     signify absolute or relative evaluation of a client
     identifier, perhaps the client network address, and a unique number
     generated by the client, perhaps the RPC transaction identifier,
     may be appropriate.

     If the object does not exist, the server creates the object and
     stores the verifier in stable storage. For file systems an NFS URL respectively.

     Note that do not
     provide a mechanism for the storage of arbitrary file attributes, there are warnings mentioned in [RFC2224] with respect to
     the server may use one or more elements of absolute evaluation and the object meta-data to
     store restrictions the verifier. The verifier must be stored in stable storage
     to prevent erroneous failure server may
     place on retransmission that evaluation with respect to how much of the request. its namespace
     has been made available.  These same warnings apply to NFS version
     4.  It is assumed likely, therefore that because of server implementation
     details, an exclusive create NFS version 3 absolute public filehandle lookup may
     behave differently than an NFS version 4 absolute resolution.

     There is being performed because
     exclusive semantics are critical to the application. Because a form of security negotiation as described in [RFC2755]
     that uses the
     expected usage, exclusive CREATE does not rely solely on the
     normally volatile duplicate request cache for storage public filehandle a method of the
     verifier. The duplicate request cache in volatile storage does employing SNEGO.  This
     method is not
     survive a crash available with NFS version 4 as filehandles are not
     overloaded with special meaning and may actually flush on a long network partition,
     opening failure windows.  In the UNIX local file system
     environment, the expected storage location for the verifier on
     creation is the meta-data (time stamps) of the object. For this
     reason, an exclusive object create may therefore do not include initial
     attributes because provide the server would have nowhere to store
     same framework as NFS versions 2 and 3.  Clients should therefore
     use the
     verifier. security negotiation mechanisms described in this RFC.

   ERRORS

     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_WRONGSEC

Draft Specification      NFS version 4 Protocol                July              August 2002

     If the server can not support these exclusive create semantics,
     possibly because of the requirement to commit the verifier to
     stable storage, it should fail

14.2.22.  Operation 24: PUTROOTFH - Set Root Filehandle

   SYNOPSIS

     - -> (cfh)

   ARGUMENT

     void;

   RESULT

     struct PUTROOTFH4res {
             /* CURRENT_FH: root fh */
             nfsstat4        status;
     };

   DESCRIPTION

     Replaces the OPEN request current filehandle with the error,
     NFS4ERR_NOTSUPP.

     During an exclusive CREATE request, if filehandle that represents
     the object already exists, root of the server reconstructs server's name space.  From this filehandle a LOOKUP
     operation can locate any other filehandle on the object's verifier and compares it server. This
     filehandle may be different from the "public" filehandle which may
     be associated with some other directory on the verifier server.

   IMPLEMENTATION

     Commonly used as the first operator in an NFS request to set the request. If they match,
     context for following operations.

   ERRORS

     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_WRONGSEC

Draft Specification      NFS version 4 Protocol              August 2002

14.2.23.  Operation 25: READ - Read from File

   SYNOPSIS

     (cfh), stateid, offset, count -> eof, data

   ARGUMENT

     struct READ4args {
             /* CURRENT_FH: file */
             stateid4        stateid;
             offset4         offset;
             count4          count;
     };

   RESULT

     struct READ4resok {
             bool            eof;
             opaque          data<>;
     };

     union READ4res switch (nfsstat4 status) {
      case NFS4_OK:
              READ4resok     resok4;
      default:
              void;
     };

   DESCRIPTION

     The READ operation reads data from the server treats regular file identified by
     the
     request as a success. current filehandle.

     The request client provides an offset of where the READ is presumed to be start and a duplicate
     count of
     an earlier, successful request for which how many bytes are to be read.  An offset of 0 (zero)
     means to read data starting at the reply was lost and
     that beginning of the server duplicate request cache mechanism did not detect. file.  If
     offset is greater than or equal to the verifiers do not match, size of the request is rejected with file, the
     status, NFS4ERR_EXIST.

     Once the client has performed a successful exclusive create, it
     must issue NFS4_OK, is returned with a SETATTR data length set to 0 (zero) and
     eof is set to TRUE.  The READ is subject to access permissions
     checking.

     If the correct object attributes.  Until
     it does so, it should not rely upon any client specifies a count value of 0 (zero), the object attributes,
     since the READ
     succeeds and returns 0 (zero) bytes of data again subject to access
     permissions checking.  The server implementation may need to overload object meta-
     data choose to store return fewer bytes
     than specified by the verifier. client.  The subsequent SETATTR must not occur
     in the same COMPOUND request as the OPEN.  This separation will
     guarantee that the exclusive create mechanism will continue client needs to
     function properly in the face of retransmission of the request.

     Use of check for this
     condition and handle the GUARDED attribute does not provide exactly-once
     semantics.  In particular, if condition appropriately.

     The stateid value for a reply READ request represents a value returned

Draft Specification      NFS version 4 Protocol              August 2002

     from a previous record lock or share reservation request.  The
     stateid is lost and used by the server does
     not detect the retransmission of the request, the procedure can
     fail with NFS4ERR_EXIST, even though the create was performed
     successfully.  The client would use this behavior in the case to verify that the application has not requested an exclusive create but has asked associated share
     reservation and any record locks are still valid and to have update
     lease timeouts for the file truncated when client.

     If the file read ended at the end-of-file (formally, in a correctly
     formed READ request, if offset + count is opened.  In equal to the case size of the client timing out and retransmitting
     file), or the create request, read request extends beyond the
     client can use GUARDED to prevent against a sequence like: create,
     write, create (retransmitted) from occurring.

     For SHARE reservations, size of the client must specify a value for access
     that file (if
     offset + count is one of READ, WRITE, or BOTH.  For deny, greater than the client must
     specify one size of NONE, READ, WRITE, or BOTH.  If the client fails to
     do this, the server must file), eof is
     returned as TRUE; otherwise it is FALSE.  A successful READ of an
     empty file will always return NFS4ERR_INVAL. eof as TRUE.

     If the component provided to OPEN current filehandle is not a symbolic link, the regular file, an error
     NFS4ERR_SYMLINK will be
     returned to the client.  If  In the case the current filehandle is not
     represents a directory, the error NFS4ERR_NOTDIR will be
     returned.

   ERRORS

     NFS4ERR_ACCESS
     NFS4ERR_ATTRNOTSUPP
     NFS4ERR_BAD_SEQID
     NFS4ERR_BADXDR
     NFS4ERR_DELAY

Draft Specification      NFS version 4 Protocol                July 2002

     NFS4ERR_DQUOT
     NFS4ERR_EXIST
     NFS4ERR_EXPIRED
     NFS4ERR_FHEXPIRED
     NFS4ERR_GRACE
     NFS4ERR_IO NFS4ERR_ISDIR
     NFS4ERR_LEASE_MOVED
     NFS4ERR_MOVED
     NFS4ERR_NAMETOOLONG
     NFS4ERR_NOENT*
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_NO_GRACE
     NFS4ERR_NOSPC
     NFS4ERR_NOTDIR
     NFS4ERR_NOTSUPP
     NFS4ERR_RECLAIM_BAD
     NFS4ERR_RECLAIM_CONFLICT
     NFS4ERR_RESOURCE
     NFS4ERR_ROFS
     NFS4ERR_SERVERFAULT
     NFS4ERR_SHARE_DENIED
     NFS4ERR_STALE_CLIENTID
     NFS4ERR_SYMLINK

Draft Specification      NFS version 4 Protocol                July 2002

14.2.17.  Operation 19: OPENATTR - Open Named Attribute Directory

   SYNOPSIS

     (cfh) createdir -> (cfh)

   ARGUMENT

     struct OPENATTR4args {
             /* CURRENT_FH: object */
             bool    createdir;
     };

   RESULT

     struct OPENATTR4res {
             /* CURRENT_FH: named attr directory*/
             nfsstat4        status;
     };

   DESCRIPTION

     The OPENATTR operation is used to obtain the filehandle return; otherwise,
     NFS4ERR_INVAL is returned.

     For a READ with a stateid value of all bits 0, the
     named attribute directory associated with server MAY allow
     the READ to be serviced subject to mandatory file locks or the
     current filehandle.
     The result of share deny modes for the OPENATTR will be file.  For a READ with a stateid
     value of all bits 1, the server MAY allow READ operations to bypass
     locking checks at the server.

     On success, the current filehandle retains its value.

   IMPLEMENTATION

     It is possible for the server to an object return fewer than count bytes of
     type NF4ATTRDIR.  From this filehandle, READDIR
     data.  If the server returns less than the count requested and LOOKUP
     procedures can be used eof
     is set to obtain filehandles for FALSE, the various named
     attributes associated with client should issue another READ to get the original
     remaining data.  A server may return less data than requested under
     several circumstances.  The file system object.
     Filehandles returned within the named attribute directory will may have
     a type of NF4NAMEDATTR.

     The createdir argument allows been truncated by another
     client or perhaps on the server itself, changing the file size from
     what the requesting client believes to signify if a named
     attribute directory should be created as a result of the OPENATTR
     operation.  Some clients may use case.  This would
     reduce the OPENATTR operation with a
     value actual amount of FALSE for createdir data available to determine if any named attributes
     exist for the object.  If none exist, then NFS4ERR_NOENT will be
     returned.  If createdir has a value of TRUE and no named attribute
     directory exists, one client.  It is created.  The creation of a named
     attribute directory assumes
     possible that the server has implemented named
     attribute support in this fashion may back off the transfer size and reduce
     the read request return.  Server resource exhaustion may also occur
     necessitating a smaller read return.

     If mandatory file locking is not required on for the file, and if the region
     corresponding to do so by
     this definition.

   IMPLEMENTATION

     If the server does data to be read from file is write locked by
     an owner not support named attributes for associated the current
     filehandle, an error of NFS4ERR_NOTSUPP stateid, server will be returned return an
     NFS4ERR_LOCKED error.  The client should try to get appropriate
     read record lock via the LOCK operation before re-attempting the
     client.
     READ. When the READ completes, the client should release the record
     lock via LOCKU.

   ERRORS

     NFS4ERR_ACCESS

Draft Specification      NFS version 4 Protocol                July              August 2002

   ERRORS

     NFS4ERR_ACCESS

     NFS4ERR_BADHANDLE
     NFS4ERR_BAD_STATEID
     NFS4ERR_BADXDR
     NFS4ERR_DELAY
     NFS4ERR_ROFS
     NFS4ERR_EXPIRED
     NFS4ERR_FHEXPIRED
     NFS4ERR_GRACE
     NFS4ERR_INVAL
     NFS4ERR_IO
     NFS4ERR_ISDIR
     NFS4ERR_LEASE_MOVED
     NFS4ERR_LOCKED
     NFS4ERR_MOVED
     NFS4ERR_NOENT
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_NOSPC
     NFS4ERR_NOTSUPP
     NFS4ERR_NXIO
     NFS4ERR_OLD_STATEID
     NFS4ERR_OPENMODE
     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE
     NFS4ERR_WRONGSEC
     NFS4ERR_STALE_STATEID

Draft Specification      NFS version 4 Protocol                July              August 2002

14.2.18.

14.2.24.  Operation 20: OPEN_CONFIRM 26: READDIR - Confirm Open Read Directory

   SYNOPSIS
      (cfh), seqid, stateid-> stateid cookie, cookieverf, dircount, maxcount, attr_request ->
      cookieverf { cookie, name, attrs }

   ARGUMENT

     struct OPEN_CONFIRM4args READDIR4args {
             /* CURRENT_FH: opened file directory */
             seqid4          seqid;
             stateid4        stateid;
             nfs_cookie4     cookie;
             verifier4       cookieverf;
             count4          dircount;
             count4          maxcount;
             bitmap4         attr_request;
     };

   RESULT

     struct OPEN_CONFIRM4resok entry4 {
             stateid4        stateid;
             nfs_cookie4     cookie;
             component4      name;
             fattr4          attrs;
             entry4          *nextentry;
     };

     struct dirlist4 {
             entry4          *entries;
             bool            eof;
     };

     struct READDIR4resok {
             verifier4       cookieverf;
             dirlist4        reply;
     };

     union OPEN_CONFIRM4res READDIR4res switch (nfsstat4 status) {
      case NFS4_OK:
              OPEN_CONFIRM4resok
              READDIR4resok  resok4;
      default:
              void;
     };

   DESCRIPTION

     This

     The READDIR operation is used to confirm the sequence id usage for the
     first time that a nfs_lockowner is used by retrieves a client.  The stateid
     returned variable number of entries from the OPEN operation is used as the argument a
     filesystem directory and returns client requested attributes for this
     operation
     each entry along with the next sequence id for the nfs_lockowner.
     The sequence id passed to the OPEN_CONFIRM must be 1 (one) greater
     than the seqid passed to the OPEN operation from which the
     open_confirm value was obtained.  If the server receives an
     unexpected sequence id with respect information to allow the original open, then the
     server assumes that the client will not confirm the original OPEN
     and all state associated with the original OPEN is released by the
     server.

     On success, the current filehandle retains its value.

   IMPLEMENTATION

     A given client might generate many nfs_lockowner data structures
     for a given clientid.  The client will periodically either dispose
     of its nfs_lockowners or stop using them for indefinite periods of to request

Draft Specification      NFS version 4 Protocol                July              August 2002

     time.

     additional directory entries in a subsequent READDIR.

     The latter situation is why the NFS version 4 protocol does
     not have arguments contain a an explicit operation to exit an nfs_lockowner: such an
     operation is of no use in cookie value that situation.  Instead, to avoid
     unbounded memory use, represents where the server needs to implement a strategy for
     disposing
     READDIR should start within the directory.  A value of nfs_lockowners that have no current lock, open, or
     delegation state 0 (zero) for any files and have not been used recently.
     The time period
     the cookie is used to determine when to dispose start reading at the beginning of nfs_lockowners
     is an implementation choice.  The time period should certainly be
     no less than the lease time plus any grace period
     directory.  For subsequent READDIR requests, the server wishes
     to implement beyond client specifies a lease time.  The OPEN_CONFIRM operation
     allows the server to safely dispose of unused nfs_lockowner data
     structures.

     In the case
     cookie value that a client issues an OPEN operation and is provided by the server
     no longer has on a record of the nfs_lockowner, previous READDIR
     request.

     The cookieverf value should be set to 0 (zero) when the server needs
     ensure that this cookie
     value is 0 (zero) (first directory read).  On subsequent requests,
     it should be a new OPEN and not a replay or retransmission.

     A lazy server implementation might require confirmation for every
     nfs_lockowner for cookieverf as returned by the server.  The
     cookieverf must match that returned by the READDIR in which it has no record.  However, this is not
     necessary until the server records
     cookie was acquired.  If the fact server determines that it has disposed of
     one nfs_lockowner the cookieverf
     is no longer valid for the given clientid.

     The server directory, the error NFS4ERR_NOT_SAME
     must hold unconfirmed OPEN state until one be returned.

     The dircount portion of three
     events occur.  First, the client sends an OPEN_CONFIRM request with argument is a hint of the appropriate sequence id and stateid within maximum
     number of bytes of directory information that should be returned.
     This value represents the lease period.
     In this case, length of the OPEN state on names of the server goes to confirmed, directory
     entries and the nfs_lockowner on cookie value for these entries.  This length
     represents the server is fully established.

     Second, XDR encoding of the client sends another OPEN request with a sequence id
     that is incorrect for data (names and cookies) and not
     the nfs_lockowner (out length in the native format of sequence).  In this
     case, the server assumes server.

     The maxcount value of the second OPEN request argument is valid and the
     first one is a replay.  The server cancels maximum number of bytes
     for the OPEN state result.  This maximum size represents all of the
     first OPEN request, establishes an unconfirmed OPEN state for data being
     returned within the
     second OPEN request, READDIR4resok structure and responds to includes the second OPEN request with
     an indication that an OPEN_CONFIRM is needed. XDR
     overhead.  The process then
     repeats itself.  While there server may return less data.  If the server is
     unable to return a potential for a denial of service
     attack on single directory entry within the client, it is mitigated if maxcount
     limit, the client and server
     require error NFS4ERR_READDIR_NOSPC will be returned to the use
     client.

     Finally, attrbits represents the list of attributes to be returned
     for each directory entry supplied by the server.

     On successful return, the server's response will provide a security flavor based on Kerberos V5, LIPKEY,
     or some other flavor that uses cryptography.

     What if list of
     directory entries.  Each of these entries contains the server is in name of the unconfirmed OPEN state for
     directory entry, a given
     nfs_lockowner, cookie value for that entry, and it receives an operation on the nfs_lockowner
     that associated
     attributes as requested.  The "eof" flag has a stateid but the operation is not OPEN, or it is
     OPEN_CONFIRM but with the wrong stateid?  Then, even value of TRUE if
     there are no more entries in the seqid directory.

     The cookie value is correct, the server returns NFS4ERR_BAD_STATEID, because only meaningful to the server assumes the operation and is used as a replay: if
     "bookmark" for the server has no
     established OPEN state, then there directory entry.  As mentioned, this cookie is no way,
     used by the client for example, subsequent READDIR operations so that it may
     continue reading a LOCK
     operation could directory.  The cookie is similar in concept to
     a READ offset but should not be valid.

     Third, neither of interpreted as such by the two aforementioned events occur for client.
     Ideally, the
     nfs_lockowner within cookie value should not change if the lease period. directory is
     modified since the client may be caching these values.

     In this case, some cases, the OPEN
     state is cancelled and disposal of server may encounter an error while obtaining
     the nfs_lockowner can occur.

Draft Specification      NFS version 4 Protocol                July 2002

   ERRORS

     NFS4ERR_BADHANDLE
     NFS4ERR_BAD_SEQID
     NFS4ERR_BADXDR
     NFS4ERR_EXPIRED
     NFS4ERR_FHEXPIRED
     NFS4ERR_GRACE
     NFS4ERR_INVAL
     NFS4ERR_ISDIR
     NFS4ERR_MOVED
     NFS4ERR_NOENT
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_NOTSUPP
     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE
     NFS4ERR_WRONGSEC attributes for a directory entry.  Instead of returning an
     error for the entire READDIR operation, the server can instead

Draft Specification      NFS version 4 Protocol                July              August 2002

14.2.19.  Operation 21: OPEN_DOWNGRADE - Reduce Open File Access

   SYNOPSIS

     (cfh), stateid, seqid, access, deny -> stateid

   ARGUMENT

     struct OPEN_DOWNGRADE4args {
             /* CURRENT_FH: opened file */
             stateid4        stateid;
             seqid4          seqid;
             uint32_t        share_access;
             uint32_t        share_deny;
     };

   RESULT

     struct OPEN_DOWNGRADE4resok {
             stateid4        stateid;
     };

     union OPEN_DOWNGRADE4res switch(nfsstat4 status) {
      case NFS4_OK:
             OPEN_DOWNGRADE4resok    resok4;
      default:
             void;
     };

   This operation

     return the attribute 'fattr4_rdattr_error'.  With this, the server
     is used able to adjust communicate the access and deny bits for a given
   open.  This is necessary when a given lockowner opens failure to the same file
   multiple times with different access client and deny flags.  In this
   situation, a close of one of the open's may change not fail the appropriate
   access and deny flags to remove bits associated with open's no longer
   in effect.

   The access and deny bits specified in this
     entire operation replace in the
   current ones for instance of what might be a transient
     failure.  Obviously, the specified open file.  If either client must request the access or
     fattr4_rdattr_error attribute for this method to work properly.  If
     the deny mode specified includes bits client does not in effect request the attribute, the server has no choice
     but to return failure for the open, entire READDIR operation.

     For some filesystem environments, the
   error NFS4ERR_INVAL directory entries "." and
     ".."  have special meaning and in other environments, they may not.
     If the server supports these special entries within a directory,
     they should not be returned.  Since access returned to the client as part of the READDIR
     response.  To enable some client environments, the cookie values of
     0, 1, and deny bits 2 are subsets to be considered reserved.  Note that the UNIX
     client will use these values when combining the server's response
     and local representations to enable a fully formed UNIX directory
     presentation to the application.

     For READDIR arguments, cookie values of those already granted, it is 1 and 2 should not possible for this
   request to be denied because used
     and for READDIR results cookie values of conflicting share reservations. 0, 1, and 2 should not
     returned.

     On success, the current filehandle retains its value.

   ERRORS

     NFS4ERR_BADHANDLE

Draft Specification      NFS version 4 Protocol                July 2002

     NFS4ERR_BAD_SEQID
     NFS4ERR_BAD_STATEID
     NFS4ERR_BADXDR
     NFS4ERR_EXPIRED
     NFS4ERR_FHEXPIRED
     NFS4ERR_INVAL
     NFS4ERR_MOVED
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_OLD_STATEID
     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE
     NFS4ERR_STALE_STATEID

Draft Specification      NFS version 4 Protocol                July 2002

14.2.20.  Operation 22: PUTFH - Set Current Filehandle

   SYNOPSIS

     filehandle -> (cfh)

   ARGUMENT

     struct PUTFH4args {
             nfs_fh4         object;
     };

   RESULT

     struct PUTFH4res {
             /* CURRENT_FH: */
             nfsstat4        status;
     };

   DESCRIPTION

     Replaces the current filehandle with the filehandle provided as an
     argument.

   IMPLEMENTATION

     Commonly used as

     The server's filesystem directory representations can differ
     greatly.  A client's programming interfaces may also be bound to
     the first operator local operating environment in an a way that does not translate
     well into the NFS request protocol.  Therefore the use of the dircount and
     maxcount fields are provided to set allow the
     context for following operations.

   ERRORS

     NFS4ERR_BADHANDLE
     NFS4ERR_BADXDR
     NFS4ERR_FHEXPIRED
     NFS4ERR_MOVED
     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE
     NFS4ERR_WRONGSEC

Draft Specification      NFS version 4 Protocol                July 2002

14.2.21.  Operation 23: PUTPUBFH - Set Public Filehandle

   SYNOPSIS

     - -> (cfh)

   ARGUMENT

     void;

   RESULT

     struct PUTPUBFH4res {
             /* CURRENT_FH: public fh */
             nfsstat4        status;
     };

   DESCRIPTION

     Replaces client the ability to
     provide guidelines to the current filehandle with server.  If the filehandle that represents client is aggressive
     about attribute collection during a READDIR, the public filehandle server has an idea
     of how to limit the server's name space.  This filehandle
     may be different from encoded response.  The dircount field provides
     a hint on the "root" filehandle which may be associated
     with some other directory number of entries based solely on the server.

     The public filehandle represents names of the concepts embodied in RFC 2054,
     RFC 2055, RFC 2224.  The intent for NFS version 4
     directory entries.  Since it is that the
     public filehandle (represented by the PUTPUBFH operation) a hint, it may be used
     as possible that a method of providing WebNFS
     dircount value is zero.  In this case, the server compatibility with NFS
     versions 2 and 3.

     The public filehandle is free to ignore
     the dircount value and return directory information based on the root filehandle (represented
     specified maxcount value.

     The cookieverf may be used by the
     PUTROOTFH operation) server to help manage cookie
     values that may become stale.  It should be equivalent.  If the public and root
     filehandles are not equivalent, then the public filehandle MUST be a descendant of the root filehandle.

   IMPLEMENTATION

     Used as the first operator in an NFS request rare occurrence that
     a server is unable to set continue properly reading a directory with
     the context for
     following operations.

     With provided cookie/cookieverf pair.  The server should make every
     effort to avoid this condition since the NFS version 2 and 3 public filehandle, application at the client is
     may not be able to specify whether properly handle this type of failure.

     The use of the path name provided in cookieverf will also protect the LOOKUP should client from using
     READDIR cookie values that may be
     evaluated as either an absolute path relative to the server's root
     or relative to stale.  For example, if the public filehandle.  RFC 2224 contains further
     discussion of file
     system has been migrated, the functionality.  With NFSv4, that type of
     specification is server may or may not directly available in the LOOKUP operation.
     The reason for this is because be able to use
     the component separators needed same cookie values to
     specify absolute vs. relative are not allowed in NFS version 4. service READDIR as the previous server

Draft Specification      NFS version 4 Protocol                July              August 2002

     Therefore,

     used.  With the client is responsible for constructing its request
     such that providing the use of either PUTROOTFH or PUTPUBFH are used cookieverf, the server is able
     to
     signify absolute or relative evaluation of an NFS URL respectively.

     Note that there are warnings mentioned in RFC 2224 with respect provide the appropriate response to the use of absolute evaluation and client.  This prevents
     the restrictions case where the server may
     place on that evaluation with respect to how much of its namespace accept a cookie value but the
     underlying directory has been made available.  These same warnings apply to NFS version
     4.  It is likely, therefore that because of server implementation
     details, an NFS version 3 absolute public filehandle lookup may
     behave differently than an NFS version 4 absolute resolution.

     There changed and the response is a form of security negotiation as described in RFC 2755
     that uses invalid from
     the public filehandle a method client's context of employing SNEGO.  This
     method is not available with NFS version 4 as filehandles are its previous READDIR.

     Since some servers will not
     overloaded with special meaning be returning "." and therefore do not provide the
     same framework ".." entries as NFS
     has been done with previous versions 2 and 3.  Clients should therefore
     use of the security negotiation mechanisms described NFS protocol, the
     client that requires these entries be present in this RFC. READDIR responses
     must fabricate them.

   ERRORS

     NFS4ERR_ACCESS
     NFS4ERR_BADHANDLE
     NFS4ERR_BAD_COOKIE
     NFS4ERR_BADXDR
     NFS4ERR_DELAY
     NFS4ERR_FHEXPIRED
     NFS4ERR_INVAL
     NFS4ERR_IO
     NFS4ERR_MOVED
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_NOTDIR
     NFS4ERR_NOTSUPP
     NFS4ERR_NOT_SAME
     NFS4ERR_READDIR_NOSPC
     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_WRONGSEC
     NFS4ERR_STALE
     NFS4ERR_TOOSMALL

Draft Specification      NFS version 4 Protocol                July              August 2002

14.2.22.

14.2.25.  Operation 24: PUTROOTFH 27: READLINK - Set Root Filehandle Read Symbolic Link

   SYNOPSIS

     - ->

     (cfh) -> linktext

   ARGUMENT

     /* CURRENT_FH: symlink */
     void;

   RESULT

     struct PUTROOTFH4res READLINK4resok {
             /* CURRENT_FH: root fh */
             nfsstat4        status;
             linktext4       link;
     };

     union READLINK4res switch (nfsstat4 status) {
      case NFS4_OK:
              READLINK4resok resok4;
      default:
              void;
     };

   DESCRIPTION

     Replaces

     READLINK reads the current filehandle data associated with a symbolic link.  The data
     is a UTF-8 string that is opaque to the server.  That is, whether
     created by an NFS client or created locally on the server, the data
     in a symbolic link is not interpreted when created, but is simply
     stored.

     On success, the current filehandle that represents retains its value.

   IMPLEMENTATION

     A symbolic link is nominally a pointer to another file.  The data
     is not necessarily interpreted by the root of server, just stored in the server's
     file.  It is possible for a client implementation to store a path
     name space.  From this filehandle that is not meaningful to the server operating system in a LOOKUP
     symbolic link.  A READLINK operation can locate any other filehandle on returns the server. This
     filehandle may be different from data to the "public" filehandle which may
     be associated with some other directory client
     for interpretation. If different implementations want to share
     access to symbolic links, then they must agree on the server.

   IMPLEMENTATION

     Commonly used as
     interpretation of the first operator data in an NFS request to set the
     context for following operations. symbolic link.

     The READLINK operation is only allowed on objects of type NF4LNK.
     The server should return the error, NFS4ERR_INVAL, if the object is
     not of type, NF4LNK.

Draft Specification      NFS version 4 Protocol              August 2002

   ERRORS

     NFS4ERR_ACCESS
     NFS4ERR_BADHANDLE
     NFS4ERR_DELAY
     NFS4ERR_FHEXPIRED
     NFS4ERR_INVAL
     NFS4ERR_IO
     NFS4ERR_MOVED
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_NOTSUPP
     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_WRONGSEC
     NFS4ERR_STALE

Draft Specification      NFS version 4 Protocol                July              August 2002

14.2.23.

14.2.26.  Operation 25: READ 28: REMOVE - Read from File Remove Filesystem Object

   SYNOPSIS

     (cfh), stateid, offset, count filename -> eof, data change_info

   ARGUMENT

     struct READ4args REMOVE4args {
             /* CURRENT_FH: file directory */
             stateid4        stateid;
             offset4         offset;
             count4          count;
             component4       target;
     };

   RESULT

     struct READ4resok REMOVE4resok {
             bool            eof;
             opaque          data<>;
     };
             change_info4    cinfo;
     }

     union READ4res REMOVE4res switch (nfsstat4 status) {
      case NFS4_OK:
              READ4resok
              REMOVE4resok   resok4;
      default:
              void;
     };
     }

   DESCRIPTION

     The READ REMOVE operation reads data removes (deletes) a directory entry named by
     filename from the regular file identified by directory corresponding to the current
     filehandle.

     The client provides an offset of where  If the READ is to start and a
     count of how many bytes are entry in the directory was the last reference
     to the corresponding filesystem object, the object may be read.  An offset of 0 (zero)
     means to read data starting at
     destroyed.

     For the beginning of directory where the file.  If
     offset is greater than or equal to filename was removed, the size server
     returns change_info4 information in cinfo.  With the atomic field
     of the file, change_info4 struct, the
     status, NFS4_OK, is returned with a data length set to 0 (zero) server will indicate if the before
     and
     eof is set to TRUE.  The READ is subject after change attributes were obtained atomically with respect
     to access permissions
     checking. the removal.

     If the client specifies target has a count value length of 0 (zero), or if target does not obey
     the READ
     succeeds and returns 0 (zero) bytes of data again subject to access
     permissions checking.  The server may choose to return fewer bytes
     than specified by UTF-8 definition, the client.  The client needs to check for this
     condition and handle error NFS4ERR_INVAL will be returned.

     On success, the condition appropriately.

     The stateid value for a READ request represents current filehandle retains its value.

   IMPLEMENTATION

     NFS versions 2 and 3 required a value returned different operator RMDIR for

Draft Specification      NFS version 4 Protocol                July              August 2002

     from a previous record lock or share reservation request.  Used by
     the server to verify that the associated lock is still valid

     directory removal and to
     update lease timeouts REMOVE for non-directory removal. This
     allowed clients to skip checking the client.

     If the read ended at the end-of-file (formally, in file type when being passed a correctly
     formed READ request, if offset + count is equal
     no