draft-ietf-nfsv4-rfc3530bis-29.txt   draft-ietf-nfsv4-rfc3530bis-30.txt 
NFSv4 T. Haynes, Ed. NFSv4 T. Haynes, Ed.
Internet-Draft NetApp Internet-Draft NetApp
Obsoletes: 3530 (if approved) D. Noveck, Ed. Obsoletes: 3530 (if approved) D. Noveck, Ed.
Intended status: Standards Track EMC Intended status: Standards Track EMC
Expires: June 1, 2014 November 28, 2013 Expires: July 13, 2014 January 09, 2014
Network File System (NFS) Version 4 Protocol Network File System (NFS) Version 4 Protocol
draft-ietf-nfsv4-rfc3530bis-29.txt draft-ietf-nfsv4-rfc3530bis-30.txt
Abstract Abstract
The Network File System (NFS) version 4 is a distributed file system The Network File System (NFS) version 4 is a distributed file system
protocol which builds on the heritage of NFS protocol version 2, RFC protocol which builds on the heritage of NFS protocol version 2, RFC
1094, and version 3, RFC 1813. Unlike earlier versions, the NFS 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS
version 4 protocol supports traditional file access while integrating version 4 protocol supports traditional file access while integrating
support for file locking and the mount protocol. In addition, support for file locking and the mount protocol. In addition,
support for strong security (and its negotiation), compound support for strong security (and its negotiation), compound
operations, client caching, and internationalization have been added. operations, client caching, and internationalization have been added.
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 1, 2014. This Internet-Draft will expire on July 13, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 6, line 14 skipping to change at page 6, line 14
10.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 159 10.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 159
10.7. Data and Metadata Caching and Memory Mapped Files . . . 161 10.7. Data and Metadata Caching and Memory Mapped Files . . . 161
10.8. Name Caching . . . . . . . . . . . . . . . . . . . . . . 163 10.8. Name Caching . . . . . . . . . . . . . . . . . . . . . . 163
10.9. Directory Caching . . . . . . . . . . . . . . . . . . . 164 10.9. Directory Caching . . . . . . . . . . . . . . . . . . . 164
11. Minor Versioning . . . . . . . . . . . . . . . . . . . . . . 165 11. Minor Versioning . . . . . . . . . . . . . . . . . . . . . . 165
12. Internationalization . . . . . . . . . . . . . . . . . . . . 168 12. Internationalization . . . . . . . . . . . . . . . . . . . . 168
12.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 168 12.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 168
12.2. Limitations on internationalization-related 12.2. Limitations on internationalization-related
processing in the NFSv4 context . . . . . . . . . . . . 169 processing in the NFSv4 context . . . . . . . . . . . . 169
12.3. String Encoding . . . . . . . . . . . . . . . . . . . . 169 12.3. Summary of Server Behavior Types . . . . . . . . . . . . 170
12.4. Normalization . . . . . . . . . . . . . . . . . . . . . 170 12.4. String Encoding . . . . . . . . . . . . . . . . . . . . 171
12.5. Types with Processing Defined by Other Internet Areas . 171 12.5. Normalization . . . . . . . . . . . . . . . . . . . . . 171
12.6. UTF-8 Related Errors . . . . . . . . . . . . . . . . . . 172 12.6. Types with Processing Defined by Other Internet Areas . 172
12.7. Handling of component names that are not valid UTF-8 12.7. UTF-8 Related Errors . . . . . . . . . . . . . . . . . . 173
strings . . . . . . . . . . . . . . . . . . . . . . . . 172 12.8. Servers that accept file component names that are not
13. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 173 valid UTF-8 strings . . . . . . . . . . . . . . . . . . 174
13.1. Error Definitions . . . . . . . . . . . . . . . . . . . 174 13. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 175
13.1.1. General Errors . . . . . . . . . . . . . . . . . . . 175 13.1. Error Definitions . . . . . . . . . . . . . . . . . . . 175
13.1.2. Filehandle Errors . . . . . . . . . . . . . . . . . 176 13.1.1. General Errors . . . . . . . . . . . . . . . . . . . 177
13.1.3. Compound Structure Errors . . . . . . . . . . . . . 178 13.1.2. Filehandle Errors . . . . . . . . . . . . . . . . . 178
13.1.4. File System Errors . . . . . . . . . . . . . . . . . 179 13.1.3. Compound Structure Errors . . . . . . . . . . . . . 179
13.1.5. State Management Errors . . . . . . . . . . . . . . 181 13.1.4. File System Errors . . . . . . . . . . . . . . . . . 180
13.1.6. Security Errors . . . . . . . . . . . . . . . . . . 182 13.1.5. State Management Errors . . . . . . . . . . . . . . 182
13.1.7. Name Errors . . . . . . . . . . . . . . . . . . . . 182 13.1.6. Security Errors . . . . . . . . . . . . . . . . . . 183
13.1.8. Locking Errors . . . . . . . . . . . . . . . . . . . 183 13.1.7. Name Errors . . . . . . . . . . . . . . . . . . . . 184
13.1.9. Reclaim Errors . . . . . . . . . . . . . . . . . . . 184 13.1.8. Locking Errors . . . . . . . . . . . . . . . . . . . 184
13.1.10. Client Management Errors . . . . . . . . . . . . . . 185 13.1.9. Reclaim Errors . . . . . . . . . . . . . . . . . . . 186
13.1.11. Attribute Handling Errors . . . . . . . . . . . . . 185 13.1.10. Client Management Errors . . . . . . . . . . . . . . 186
13.2. Operations and their valid errors . . . . . . . . . . . 186 13.1.11. Attribute Handling Errors . . . . . . . . . . . . . 187
13.3. Callback operations and their valid errors . . . . . . . 193 13.2. Operations and their valid errors . . . . . . . . . . . 187
13.4. Errors and the operations that use them . . . . . . . . 194 13.3. Callback operations and their valid errors . . . . . . . 194
14. NFSv4 Requests . . . . . . . . . . . . . . . . . . . . . . . 198 13.4. Errors and the operations that use them . . . . . . . . 195
14.1. Compound Procedure . . . . . . . . . . . . . . . . . . . 199 14. NFSv4 Requests . . . . . . . . . . . . . . . . . . . . . . . 199
14.2. Evaluation of a Compound Request . . . . . . . . . . . . 199 14.1. Compound Procedure . . . . . . . . . . . . . . . . . . . 200
14.3. Synchronous Modifying Operations . . . . . . . . . . . . 200 14.2. Evaluation of a Compound Request . . . . . . . . . . . . 200
14.4. Operation Values . . . . . . . . . . . . . . . . . . . . 200 14.3. Synchronous Modifying Operations . . . . . . . . . . . . 201
15. NFSv4 Procedures . . . . . . . . . . . . . . . . . . . . . . 201 14.4. Operation Values . . . . . . . . . . . . . . . . . . . . 201
15.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 201 15. NFSv4 Procedures . . . . . . . . . . . . . . . . . . . . . . 202
15.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 201 15.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 202
15.3. Operation 3: ACCESS - Check Access Rights . . . . . . . 205 15.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 202
15.4. Operation 4: CLOSE - Close File . . . . . . . . . . . . 208 15.3. Operation 3: ACCESS - Check Access Rights . . . . . . . 206
15.5. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 209 15.4. Operation 4: CLOSE - Close File . . . . . . . . . . . . 209
15.6. Operation 6: CREATE - Create a Non-Regular File Object . 211 15.5. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 210
15.6. Operation 6: CREATE - Create a Non-Regular File Object . 212
15.7. Operation 7: DELEGPURGE - Purge Delegations Awaiting 15.7. Operation 7: DELEGPURGE - Purge Delegations Awaiting
Recovery . . . . . . . . . . . . . . . . . . . . . . . . 214 Recovery . . . . . . . . . . . . . . . . . . . . . . . . 215
15.8. Operation 8: DELEGRETURN - Return Delegation . . . . . . 215 15.8. Operation 8: DELEGRETURN - Return Delegation . . . . . . 216
15.9. Operation 9: GETATTR - Get Attributes . . . . . . . . . 216 15.9. Operation 9: GETATTR - Get Attributes . . . . . . . . . 217
15.10. Operation 10: GETFH - Get Current Filehandle . . . . . . 218 15.10. Operation 10: GETFH - Get Current Filehandle . . . . . . 219
15.11. Operation 11: LINK - Create Link to a File . . . . . . . 219 15.11. Operation 11: LINK - Create Link to a File . . . . . . . 220
15.12. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 220 15.12. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 221
15.13. Operation 13: LOCKT - Test For Lock . . . . . . . . . . 224 15.13. Operation 13: LOCKT - Test For Lock . . . . . . . . . . 225
15.14. Operation 14: LOCKU - Unlock File . . . . . . . . . . . 226 15.14. Operation 14: LOCKU - Unlock File . . . . . . . . . . . 227
15.15. Operation 15: LOOKUP - Lookup Filename . . . . . . . . . 227 15.15. Operation 15: LOOKUP - Lookup Filename . . . . . . . . . 228
15.16. Operation 16: LOOKUPP - Lookup Parent Directory . . . . 229 15.16. Operation 16: LOOKUPP - Lookup Parent Directory . . . . 230
15.17. Operation 17: NVERIFY - Verify Difference in 15.17. Operation 17: NVERIFY - Verify Difference in
Attributes . . . . . . . . . . . . . . . . . . . . . . . 230 Attributes . . . . . . . . . . . . . . . . . . . . . . . 231
15.18. Operation 18: OPEN - Open a Regular File . . . . . . . . 231 15.18. Operation 18: OPEN - Open a Regular File . . . . . . . . 232
15.19. Operation 19: OPENATTR - Open Named Attribute 15.19. Operation 19: OPENATTR - Open Named Attribute
Directory . . . . . . . . . . . . . . . . . . . . . . . 241 Directory . . . . . . . . . . . . . . . . . . . . . . . 242
15.20. Operation 20: OPEN_CONFIRM - Confirm Open . . . . . . . 242 15.20. Operation 20: OPEN_CONFIRM - Confirm Open . . . . . . . 243
15.21. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 244 15.21. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 245
15.22. Operation 22: PUTFH - Set Current Filehandle . . . . . . 245 15.22. Operation 22: PUTFH - Set Current Filehandle . . . . . . 246
15.23. Operation 23: PUTPUBFH - Set Public Filehandle . . . . . 246 15.23. Operation 23: PUTPUBFH - Set Public Filehandle . . . . . 247
15.24. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 247 15.24. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 248
15.25. Operation 25: READ - Read from File . . . . . . . . . . 248 15.25. Operation 25: READ - Read from File . . . . . . . . . . 249
15.26. Operation 26: READDIR - Read Directory . . . . . . . . . 250 15.26. Operation 26: READDIR - Read Directory . . . . . . . . . 251
15.27. Operation 27: READLINK - Read Symbolic Link . . . . . . 254 15.27. Operation 27: READLINK - Read Symbolic Link . . . . . . 255
15.28. Operation 28: REMOVE - Remove Filesystem Object . . . . 255 15.28. Operation 28: REMOVE - Remove Filesystem Object . . . . 256
15.29. Operation 29: RENAME - Rename Directory Entry . . . . . 257 15.29. Operation 29: RENAME - Rename Directory Entry . . . . . 258
15.30. Operation 30: RENEW - Renew a Lease . . . . . . . . . . 259 15.30. Operation 30: RENEW - Renew a Lease . . . . . . . . . . 260
15.31. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 260 15.31. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 261
15.32. Operation 32: SAVEFH - Save Current Filehandle . . . . . 261 15.32. Operation 32: SAVEFH - Save Current Filehandle . . . . . 262
15.33. Operation 33: SECINFO - Obtain Available Security . . . 262 15.33. Operation 33: SECINFO - Obtain Available Security . . . 263
15.34. Operation 34: SETATTR - Set Attributes . . . . . . . . . 266 15.34. Operation 34: SETATTR - Set Attributes . . . . . . . . . 267
15.35. Operation 35: SETCLIENTID - Negotiate Client ID . . . . 268 15.35. Operation 35: SETCLIENTID - Negotiate Client ID . . . . 269
15.36. Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID . 272 15.36. Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID . 273
15.37. Operation 37: VERIFY - Verify Same Attributes . . . . . 275 15.37. Operation 37: VERIFY - Verify Same Attributes . . . . . 276
15.38. Operation 38: WRITE - Write to File . . . . . . . . . . 277 15.38. Operation 38: WRITE - Write to File . . . . . . . . . . 278
15.39. Operation 39: RELEASE_LOCKOWNER - Release Lockowner 15.39. Operation 39: RELEASE_LOCKOWNER - Release Lockowner
State . . . . . . . . . . . . . . . . . . . . . . . . . 281 State . . . . . . . . . . . . . . . . . . . . . . . . . 282
15.40. Operation 10044: ILLEGAL - Illegal operation . . . . . . 282 15.40. Operation 10044: ILLEGAL - Illegal operation . . . . . . 283
16. NFSv4 Callback Procedures . . . . . . . . . . . . . . . . . . 283 16. NFSv4 Callback Procedures . . . . . . . . . . . . . . . . . . 284
16.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 283 16.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 284
16.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 283 16.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 284
16.2.6. Operation 3: CB_GETATTR - Get Attributes . . . . . . 285 16.2.6. Operation 3: CB_GETATTR - Get Attributes . . . . . . 286
16.2.7. Operation 4: CB_RECALL - Recall an Open Delegation . 286 16.2.7. Operation 4: CB_RECALL - Recall an Open Delegation . 287
16.2.8. Operation 10044: CB_ILLEGAL - Illegal Callback 16.2.8. Operation 10044: CB_ILLEGAL - Illegal Callback
Operation . . . . . . . . . . . . . . . . . . . . . 287 Operation . . . . . . . . . . . . . . . . . . . . . 288
17. Security Considerations . . . . . . . . . . . . . . . . . . . 288 17. Security Considerations . . . . . . . . . . . . . . . . . . . 289
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 290 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 291
18.1. Named Attribute Definitions . . . . . . . . . . . . . . 290 18.1. Named Attribute Definitions . . . . . . . . . . . . . . 291
18.1.1. Initial Registry . . . . . . . . . . . . . . . . . . 291 18.1.1. Initial Registry . . . . . . . . . . . . . . . . . . 292
18.1.2. Updating Registrations . . . . . . . . . . . . . . . 291 18.1.2. Updating Registrations . . . . . . . . . . . . . . . 292
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 291 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 292
19.1. Normative References . . . . . . . . . . . . . . . . . . 291 19.1. Normative References . . . . . . . . . . . . . . . . . . 292
19.2. Informative References . . . . . . . . . . . . . . . . . 292 19.2. Informative References . . . . . . . . . . . . . . . . . 293
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 296
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 295 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 297
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 296 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 297
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 296
1. Introduction 1. Introduction
1.1. NFS Version 4 Goals 1.1. NFS Version 4 Goals
The Network Filesystem version 4 (NFSv4) protocol is a further The Network Filesystem version 4 (NFSv4) protocol is a further
revision of the NFS protocol defined already by versions 2 [RFC1094] revision of the NFS protocol defined already by versions 2 [RFC1094]
and 3 [RFC1813]. It retains the essential characteristics of and 3 [RFC1813]. It retains the essential characteristics of
previous versions: design for easy recovery, independent of transport previous versions: design for easy recovery, independent of transport
protocols, operating systems and file systems, simplicity, and good protocols, operating systems and file systems, simplicity, and good
skipping to change at page 19, line 9 skipping to change at page 19, line 9
| nfs_ftype4 | enum nfs_ftype4; | | nfs_ftype4 | enum nfs_ftype4; |
| | Various defined file types. | | | Various defined file types. |
| nfsstat4 | enum nfsstat4; | | nfsstat4 | enum nfsstat4; |
| | Return value for operations. | | | Return value for operations. |
| offset4 | typedef uint64_t offset4; | | offset4 | typedef uint64_t offset4; |
| | Various offset designations (READ, WRITE, LOCK, | | | Various offset designations (READ, WRITE, LOCK, |
| | COMMIT). | | | COMMIT). |
| qop4 | typedef uint32_t qop4; | | qop4 | typedef uint32_t qop4; |
| | Quality of protection designation in SECINFO. | | | Quality of protection designation in SECINFO. |
| sec_oid4 | typedef opaque sec_oid4<>; | | sec_oid4 | typedef opaque sec_oid4<>; |
| | Security Object Identifier. The sec_oid4 data | | | Security Object Identifier. The sec_oid4 data |
| | type is not really opaque. Instead it contains | | | type is not really opaque. Instead it contains |
| | an ASN.1 OBJECT IDENTIFIER as used by GSS-API | | | an ASN.1 OBJECT IDENTIFIER as used by GSS-API |
| | in the mech_type argument to | | | in the mech_type argument to |
| | GSS_Init_sec_context. See [RFC2743] for | | | GSS_Init_sec_context. See [RFC2743] for |
| | details. | | | details. |
| seqid4 | typedef uint32_t seqid4; | | seqid4 | typedef uint32_t seqid4; |
| | Sequence identifier used for file locking. | | | Sequence identifier used for file locking. |
| utf8string | typedef opaque utf8string<>; | | utf8string | typedef opaque utf8string<>; |
| | UTF-8 encoding for strings. | | | UTF-8 encoding for strings. |
| utf8str_cis | typedef utf8string utf8str_cis; | | utf8str_cis | typedef utf8string utf8str_cis; |
| | Case-insensitive UTF-8 string. | | | Case-insensitive UTF-8 string. |
| utf8str_cs | typedef utf8string utf8str_cs; | | utf8str_cs | typedef utf8string utf8str_cs; |
| | Case-sensitive UTF-8 string. | | | Case-sensitive UTF-8 string. |
| utf8str_mixed | typedef utf8string utf8str_mixed; | | utf8str_mixed | typedef utf8string utf8str_mixed; |
skipping to change at page 51, line 21 skipping to change at page 51, line 21
As mentioned above, it is desirable that a server when accepting a As mentioned above, it is desirable that a server when accepting a
string of the form user@domain or group@domain in an attribute, string of the form user@domain or group@domain in an attribute,
return this same string when that corresponding attribute is fetched. return this same string when that corresponding attribute is fetched.
Internationalization issues (for a general discussion of which see Internationalization issues (for a general discussion of which see
Section 12) may make this impossible and the client needs to take Section 12) may make this impossible and the client needs to take
note of the following situations: note of the following situations:
o The string representing the domain may be converted to equivalent o The string representing the domain may be converted to equivalent
U-label (see [RFC5890]), if presented using a form other than a U-label (see [RFC5890]), if presented using a form other than a
U-label. See Section 12.5 for details. U-label. See Section 12.6 for details.
o The user or group may be returned in a different form, due to o The user or group may be returned in a different form, due to
normalization issues, although it will always be a canonically normalization issues, although it will always be a canonically
equivalent string. equivalent string.
In the case where there is no translation available to the client or In the case where there is no translation available to the client or
server, the attribute value will be constructed without the "@". server, the attribute value will be constructed without the "@".
Therefore, the absence of the "@" from the owner or owner_group Therefore, the absence of the "@" from the owner or owner_group
attribute signifies that no translation was available at the sender attribute signifies that no translation was available at the sender
and that the receiver of the attribute should not use that string as and that the receiver of the attribute should not use that string as
skipping to change at page 123, line 30 skipping to change at page 123, line 30
some information in stable storage. The amount of information the some information in stable storage. The amount of information the
server records in stable storage is in inverse proportion to how server records in stable storage is in inverse proportion to how
harsh the server wants to be whenever the edge conditions occur. The harsh the server wants to be whenever the edge conditions occur. The
server that is completely tolerant of all edge conditions will record server that is completely tolerant of all edge conditions will record
in stable storage every lock that is acquired, removing the lock in stable storage every lock that is acquired, removing the lock
record from stable storage only when the lock is unlocked by the record from stable storage only when the lock is unlocked by the
client and the lock's owner advances the sequence number such that client and the lock's owner advances the sequence number such that
the lock release is not the last stateful event for the owner's the lock release is not the last stateful event for the owner's
sequence. For the two aforementioned edge conditions, the harshest a sequence. For the two aforementioned edge conditions, the harshest a
server can be, and still support a grace period for reclaims, server can be, and still support a grace period for reclaims,
requires that the server record in stable storage information some requires that the server record in stable storage some minimal
minimal information. For example, a server implementation could, for information. For example, a server implementation could, for each
each client, save in stable storage a record containing: client, save in stable storage a record containing:
o the client's id string o the client's id string
o a boolean that indicates if the client's lease expired or if there o a boolean that indicates if the client's lease expired or if there
was administrative intervention (see Section 9.8) to revoke a was administrative intervention (see Section 9.8) to revoke a
byte-range lock, share reservation, or delegation byte-range lock, share reservation, or delegation
o a timestamp that is updated the first time after a server boot or o a timestamp that is updated the first time after a server boot or
reboot the client acquires byte-range locking, share reservation, reboot the client acquires byte-range locking, share reservation,
or delegation state on the server. The timestamp need not be or delegation state on the server. The timestamp need not be
skipping to change at page 168, line 16 skipping to change at page 168, line 16
12.1. Introduction 12.1. Introduction
This section uses NFSv4.0 internationalization, as implemented by This section uses NFSv4.0 internationalization, as implemented by
existing clients and servers, as the basis upon which NFSv4.0 clients existing clients and servers, as the basis upon which NFSv4.0 clients
may implement internationalization support. This procedure, while may implement internationalization support. This procedure, while
necessary, may result in confusion if we do not clearly understand necessary, may result in confusion if we do not clearly understand
that we are mixing prescription and description, and why, in this that we are mixing prescription and description, and why, in this
particular case, this is a valid thing to do. particular case, this is a valid thing to do.
Note that in this chapter, the keywords "MUST", "SHOULD", and "MAY", This section is based on the behavior of existing implementations.
Note that the behaviors described are each demonstrated by a
combination of an NFSv4 server implementation proper and a server-
side physical filesystem. It is common for servers and physical
filesystems to be configurable as to the behavior shown once set up
and each be configuration showing different behavior is considered
separately, for our purposes.
Note that in this section, the keywords "MUST", "SHOULD", and "MAY",
retain their normal meanings. However, in deriving this retain their normal meanings. However, in deriving this
specification from implementation patterns, we document below how the specification from implementation patterns, we document below how the
normative terms used derive from the behavior of existing normative terms used derive from the behavior of existing
implementations. implementations, in those situations in which existing implementation
behavior patterns can be determined.
o Behavior implemented by all existing clients or servers is o Behavior implemented by all existing clients or servers is
described using "MUST", since new implementations need to follow described using "MUST", since new implementations need to follow
existing ones to be assured of interoperability. While it is existing ones to be assured of interoperability. While it is
possible that different behavior might be workable, we have found possible that different behavior might be workable, we have found
no case where this seems reasonable. no case where this seems reasonable.
o Behavior implemented by no existing clients or servers is o Behavior implemented by no existing clients or servers is
described using "MUST NOT", if such behavior poses described using "MUST NOT", if such behavior poses
interoperability problems. interoperability problems.
skipping to change at page 168, line 52 skipping to change at page 169, line 12
implementations will have the same flexibility that existing ones implementations will have the same flexibility that existing ones
do. do.
o Behavior implemented by all existing clients or servers, so far as o Behavior implemented by all existing clients or servers, so far as
is known, but where there remains some uncertainty as to details is known, but where there remains some uncertainty as to details
is described using "should". Such cases primarily concern details is described using "should". Such cases primarily concern details
of error returns. New implementations should follow existing of error returns. New implementations should follow existing
practice even though such situations generally do not affect practice even though such situations generally do not affect
interoperability. interoperability.
There are also cases in which certain server behaviors, while not
known to exist, cannot be reliably determined not to exist. In part,
this is a consequence of the long period of time that has elapsed
since the publication of [RFC3530], resulting in a situation in which
those involved in the implementation may no longer be involved in or
aware of working group activities.
In the case of possible server behavior that is neither known to
exist nor known not to exist, we use SHOULD NOT and MUST NOT as
follows, and similarly for "SHOULD" and "MUST".
o In some cases, the potential behavior is not known to exist but is
of such a nature that, if it were in fact implemented,
interoperability difficulties would be expected and reported,
giving us cause to conclude that the potential behavior is not
implemented. For such behavior, we use MUST NOT. Similarly we
use "MUST" to apply to the contrary behavior.
o In other cases, potential behavior is not known to exist but the
behavior, while undesirable, is not of such a nature that we are
able to draw any conclusions about its potential existence. In
such cases, we use SHOULD NOT. Similarly we use "SHOULD" to apply
to the contrary behavior.
In the case of a MAY, SHOULD, or SHOULD NOT that applies to servers, In the case of a MAY, SHOULD, or SHOULD NOT that applies to servers,
clients need to be aware that there are servers which may or may not clients need to be aware that there are servers which may or may not
take the specified action, and they need to be prepared for either take the specified action, and they need to be prepared for either
eventuality. eventuality.
12.2. Limitations on internationalization-related processing in the 12.2. Limitations on internationalization-related processing in the
NFSv4 context NFSv4 context
There are a number of noteworthy circumstances that limit the degree There are a number of noteworthy circumstances that limit the degree
to which internationalization-related processing can be made to which internationalization-related processing can be made
skipping to change at page 169, line 34 skipping to change at page 170, line 19
o Typical implementation patterns in Unix systems may mean that the o Typical implementation patterns in Unix systems may mean that the
NFSv4 client has no knowledge of the character encoding being NFSv4 client has no knowledge of the character encoding being
used, which may even vary between processes on the same client used, which may even vary between processes on the same client
system. system.
o Users may need access to files stored previously with non-UTF-8 o Users may need access to files stored previously with non-UTF-8
encodings, or with UTF-8 encodings that do not match any encodings, or with UTF-8 encodings that do not match any
particular normalization form. particular normalization form.
12.3. String Encoding 12.3. Summary of Server Behavior Types
As mentioned in Section 12.6, servers MAY reject component name
strings that are not valid UTF-8. This leads to a number of types of
valid server behavior as outlined below. When these are combined
with the valid normalization-related behaviors as described in
Section 12.4, this leads to the combined behaviors outlined below.
o Servers which do limit file component names to UTF-8 strings exist
with all of the forms of normalization-related handling described
in Section 12.4. These are best described as "UTF-8-only
servers".
o Servers which do not limit file component names to UTF-8 strings
are very common and are necessary to deal with clients/
applications not oriented to the use of UTF-8. Such servers
ignore normalization-related issues and there is no way for them
to implement either normalization or representation-independent
lookups. These are best described as "UTF-8-unaware servers"
since they treat file component names as uninterpreted strings of
bytes and have no knowledge of the characters represented. Such
servers ignore normalization-related issues and there is no way
for them to implement either normalization or representation-
independent lookups. See Section 12.7 for details.
o It is possible for a server to allow component names which are not
valid UTF-8, while still being aware of the structure of UTF-8
strings. Such servers could implement either normalization or
representation-independent lookups, but apply those techniques
only to valid UTF-8 strings. Such servers are not known to exist
and SHOULD NOT be implemented because of the possibility that a
filename using one character set may, by accident, have the
appearance of a UTF-8 filename. See Section 12.7 for details.
12.4. String Encoding
Strings that potentially contain non-ASCII Characters are generally Strings that potentially contain non-ASCII Characters are generally
represented in NFSv4 using the UTF-8 encoding of Unicode. See represented in NFSv4 using the UTF-8 encoding of Unicode. See
[RFC2279] for precise encoding and decoding rules. [RFC2279] for precise encoding and decoding rules.
Some details of the protocol treatment depend on the type of string: Some details of the protocol treatment depend on the type of string:
o For strings which are component names, the preferred encoding for o For strings which are component names, the preferred encoding for
any non-ASCII characters is any non-ASCII characters is the UTF-8 any non-ASCII characters is the UTF-8 representation of Unicode.
representation of Unicode.
In many cases, clients have no knowledge of the encoding being In many cases, clients have no knowledge of the encoding being
used, with the encoding done at user-level under control of a per- used, with the encoding done at user-level under control of a per-
process locale specification. As a result, it may be impossible process locale specification. As a result, it may be impossible
for the NFSv4 client to enforce use of UTF-8. Use of non-UTF-8 for the NFSv4 client to enforce use of UTF-8. Use of non-UTF-8
encodings can be problematic since it may interfere with access to encodings can be problematic since it may interfere with access to
files stored using other forms of name encoding. Also, files stored using other forms of name encoding. Also,
normalization-related processing (see Section 12.4) of a string normalization-related processing (see Section 12.5) of a string
not encoded in UTF-8 could result in inappropriate name not encoded in UTF-8 could result in inappropriate name
modification or aliasing. In cases in which one has a non-UT8- modification or aliasing. In cases in which one has a non-UT8-
name that accidentally conforms to UTF-8 rules, substitution of name that accidentally conforms to UTF-8 rules, substitution of
canonically equivalent strings can change the non-UTF-8 encoded canonically equivalent strings can change the non-UTF-8 encoded
name drastically. name drastically.
o For strings whose form is defined by other internet standards, o For strings whose form is defined by other internet standards,
non-ASCII characters MUST be represented using the UTF-8 encoding non-ASCII characters MUST be represented using the UTF-8 encoding
of Unicode. In addition other sorts of restrictions defined by of Unicode. In addition other sorts of restrictions defined by
those standards need to be addressed. See Section 12.5 for those standards need to be addressed. See Section 12.6 for
details. details.
o The contents of symbolic links (of type linktext4 in the XDR) MUST o The contents of symbolic links (of type linktext4 in the XDR) MUST
be treated as opaque data by NFSv4 servers. Although UTF-8 be treated as opaque data by NFSv4 servers. Although UTF-8
encoding is often used, it need not be. In this respect, the encoding is often used, it need not be. In this respect, the
contents of symbolic links are like the contents of regular files contents of symbolic links are like the contents of regular files
in that their encoding is not within the scope of this in that their encoding is not within the scope of this
specification. specification.
o For other sorts of strings, any non-ASCII characters SHOULD be o For other sorts of strings, any non-ASCII characters SHOULD be
represented using the UTF-8 encoding of Unicode. represented using the UTF-8 encoding of Unicode.
12.4. Normalization 12.5. Normalization
The client and server operating environments may differ in their The client and server operating environments may differ in their
policies and operational methods with respect to character policies and operational methods with respect to character
normalization (See [Unicode1] for a discussion of normalization normalization (See [Unicode1] for a discussion of normalization
forms). This difference may also exist between applications on the forms). This difference may also exist between applications on the
same client. This adds to the difficulty of providing a single same client. This adds to the difficulty of providing a single
normalization policy for the protocol that allows for maximal normalization policy for the protocol that allows for maximal
interoperability. This issue is similar to the character case issues interoperability. This issue is similar to the character case issues
where the server may or may not support case insensitive file name where the server may or may not support case insensitive file name
matching and may or may not preserve the character case when storing matching and may or may not preserve the character case when storing
skipping to change at page 171, line 13 skipping to change at page 172, line 30
Server implementations MAY normalize file names to conform to a Server implementations MAY normalize file names to conform to a
particular normalization form before using the resulting string when particular normalization form before using the resulting string when
looking up or creating a file. Servers MAY also perform looking up or creating a file. Servers MAY also perform
normalization-insensitive string comparisons without modifying name normalization-insensitive string comparisons without modifying name
to match a particular normalization form. Except in cases in which to match a particular normalization form. Except in cases in which
component names are excluded from normalization-related handling component names are excluded from normalization-related handling
because they are not valid UTF-8 strings, a server MUST make the same because they are not valid UTF-8 strings, a server MUST make the same
choice (as to whether to normalize or not, the target form of choice (as to whether to normalize or not, the target form of
normalization and whether to do normalization-insensitive string normalization and whether to do normalization-insensitive string
comparisons) in the same way for all accesses to a particular comparisons) in the same way for all accesses to a particular
filesystem. Servers MUST NOT reject a file name because it doesn't a filesystem. Servers MUST NOT reject a file name because it does not
conform to a particular normalization form. conform to a particular normalization form.
12.5. Types with Processing Defined by Other Internet Areas 12.6. Types with Processing Defined by Other Internet Areas
There are two types of strings which NFSv4 deals with whose There are two types of strings which NFSv4 deals with whose
processing is defined by other Internet standards, and where issues processing is defined by other Internet standards, and where issues
related to different handling choices by server operating systems or related to different handling choices by server operating systems or
server file systems do not apply. server file systems do not apply.
These are as follows: These are as follows:
o Server names as they appear in the fs_locations attribute. Note o Server names as they appear in the fs_locations attribute. Note
that for most purposes, such server names will only be sent by the that for most purposes, such server names will only be sent by the
skipping to change at page 172, line 17 skipping to change at page 173, line 34
server does not map domain strings which are not U-labels into a server does not map domain strings which are not U-labels into a
U-label, which it MAY do, it MUST NOT modify the domain, and the U-label, which it MAY do, it MUST NOT modify the domain, and the
domain returned on a GETATTR of the userid MUST be the same as that domain returned on a GETATTR of the userid MUST be the same as that
used when setting the userid by the SETATTR. used when setting the userid by the SETATTR.
The server MAY implement VERIFY and NVERIFY without translating The server MAY implement VERIFY and NVERIFY without translating
internal state to a string form, so that, for example, a user internal state to a string form, so that, for example, a user
principal which represents a specific numeric user id, will match a principal which represents a specific numeric user id, will match a
different principal string which represents the same numeric user id. different principal string which represents the same numeric user id.
12.6. UTF-8 Related Errors 12.7. UTF-8 Related Errors
Where the client sends an invalid UTF-8 string, the server MAY return Where the client sends an invalid UTF-8 string, the server MAY return
an NFS4ERR_INVAL error. This includes cases in which inappropriate an NFS4ERR_INVAL error. This includes cases in which inappropriate
prefixes are detected and where the count includes trailing bytes prefixes are detected and where the count includes trailing bytes
that do not constitute a full UCS character. that do not constitute a full UCS character.
Requirements for server handling of component names which are not Requirements for server handling of component names which are not
valid UTF-8, when a server does not return NFS4ERR_INVAL in response valid UTF-8, when a server does not return NFS4ERR_INVAL in response
to receiving them, are described in Section 12.7. to receiving them, are described in Section 12.8.
Where the client supplied string is not rejected with NFS4ERR_INVAL Where the client supplied string is not rejected with NFS4ERR_INVAL
but contains characters that are not supported by the server as a but contains characters that are not supported by the server as a
value for that string (e.g., names containing slashes, or characters value for that string (e.g., names containing slashes, or characters
that have more than two octets on a filesystem that supports Unicode that have more than two octets on a filesystem that supports Unicode
characters only), the server should return an NFS4ERR_BADCHAR error. characters only), the server should return an NFS4ERR_BADCHAR error.
Where a UTF-8 string is used as a file name, and the file system, Where a UTF-8 string is used as a file name, and the file system,
while supporting all of the characters within the name, does not while supporting all of the characters within the name, does not
allow that particular name to be used, the error should return the allow that particular name to be used, the error should return the
error NFS4ERR_BADNAME. This includes such situations as file system error NFS4ERR_BADNAME. This includes such situations as file system
prohibitions of "." and ".." as file names for certain operations, prohibitions of "." and ".." as file names for certain operations,
and similar constraints and similar constraints
12.7. Handling of component names that are not valid UTF-8 strings 12.8. Servers that accept file component names that are not valid UTF-8
strings
In cases in which the server receives a component name that is not a
valid UTF-8 string, the required handling depends on whether a file
object is being created or looked up. Object creation happens for
the component name in LINK and CREATE, and the second component name
in RENAME. Object lookup happens for the component name in LOOKUP
and REMOVE, and the first component name in RENAME. The component
name in OPEN will result in object lookup and also object creation if
the lookup fails and the other OPEN parameters allow file creation.
With regard to normalization-related processing, it is generally
inhibited, both in the case of object creation and object lookup:
o Characters which are not valid UTF-8 have no canonically
equivalent Unicode string, so normalization-related processing
cannot happen.
o In cases in which a string has valid UTF-8 character strings that
do have canonically equivalent Unicode strings, but if the
component name is not valid UTF-8, the server MAY perform
normalization-related processing on valid UTF-8 substrings within
it that do have canonical equivalents.
When creation of a component name which is not valid UTF-8 occurs, As stated previously, servers MAY accept, on all or on some subset of
and is allowed by the server: the physical filesystems exported, component names that are not valid
UTF-8 strings. A typical pattern is for a server to use UTF-8-
unaware physical filesystems that treat component names as
uninterpreted strings of bytes, rather than having any awareness of
the character set being used.
o A subsequent lookup of the same component name in the same Such servers SHOULD NOT change the stored representation of component
directory MUST result in finding the created file object. names from those received on the wire, and SHOULD use binary
comparison of component name strings to determine equivalence (as
opposed to any broader notion of string comparison). This is because
the server has no knowledge of the character encoding being used.
o A READDIR of the directory in which the name is created MUST Nonetheless, when such a server uses a broader notion of string
result in an entry containing the component name used for the equivalence than recommended in the preceding paragraph the following
creation. considerations apply:
o A subsequent lookup using any other string as the component name o Outside of 7-bit ASCII, string processing that changes string
SHOULD NOT find the originally created object. contents is usually specific to a character set and hence is
generally unsafe when the character set is unknown. This
processing could change the filename in an unexpected fashion,
rendering the file inaccessible to the application or client that
created or renamed the file and to others expecting the original
filename.
o A subsequent lookup using any valid UTF-8 string MUST NOT find the o Unicode normalization is particularly dangerous, as such
originally created object. processing assumes that the string is UTF-8. When that assumption
is false because a different character set was used to create the
filename, normalization may corrupt the filename with respect to
that character set, rendering the file inaccessible to the
application that created it and others expecting the original
filename.
When a lookup of a component name which is not valid UTF-8 occurs, When non-UTF-8 component names are accepted in an environment in
and is allowed by the server: which string processing occurs (e.g., to support a broader notion of
string equivalence than binary equality), the following
considerations apply:
o The result of the lookup MUST NOT be any directory entry created o Portions of a string that are not valid UTF-8 cannot be Unicode
with a valid UTF-8 component name. normalized because they do not represent Unicode characters.
o The result of the lookup MUST be a directory entry created with o Nonetheless, it is possible to perform Unicode normalization on
the identical invalid UTF-8 string, if one exists in the valid UTF-8 substrings in a string that is not valid UTF-8 by
directory. selectively ignoring substrings that are not valid UTF-8. This
MUST NOT be done since doing so would result in incorrect string
modification or aliasing.
13. Error Values 13. Error Values
NFS error numbers are assigned to failed operations within a Compound NFS error numbers are assigned to failed operations within a Compound
(COMPOUND or CB_COMPOUND) request. A Compound request contains a (COMPOUND or CB_COMPOUND) request. A Compound request contains a
number of NFS operations that have their results encoded in sequence number of NFS operations that have their results encoded in sequence
in a Compound reply. The results of successful operations will in a Compound reply. The results of successful operations will
consist of an NFS4_OK status followed by the encoded results of the consist of an NFS4_OK status followed by the encoded results of the
operation. If an NFS operation fails, an error status will be operation. If an NFS operation fails, an error status will be
entered in the reply and the Compound request will be terminated. entered in the reply and the Compound request will be terminated.
skipping to change at page 182, line 46 skipping to change at page 184, line 17
Names in NFSv4 are UTF-8 strings. When the strings are not of length Names in NFSv4 are UTF-8 strings. When the strings are not of length
zero, the error NFS4ERR_INVAL results. When they are not valid UTF-8 zero, the error NFS4ERR_INVAL results. When they are not valid UTF-8
the error NFS4ERR_INVAL also results, but servers may accommodate the error NFS4ERR_INVAL also results, but servers may accommodate
file systems with different character formats and not return this file systems with different character formats and not return this
error. Besides this, there are a number of other errors to indicate error. Besides this, there are a number of other errors to indicate
specific problems with names. specific problems with names.
13.1.7.1. NFS4ERR_BADCHAR (Error Code 10040) 13.1.7.1. NFS4ERR_BADCHAR (Error Code 10040)
A UTF-8 string contains a character which is not supported by the A UTF-8 string contains a character which is not supported by the
server in the context in which it being used. server in the context in which it is being used.
13.1.7.2. NFS4ERR_BADNAME (Error Code 10041) 13.1.7.2. NFS4ERR_BADNAME (Error Code 10041)
A name string in a request consisted of valid UTF-8 characters A name string in a request consisted of valid UTF-8 characters
supported by the server but the name is not supported by the server supported by the server but the name is not supported by the server
as a valid name for current operation. An example might be creating as a valid name for current operation. An example might be creating
a file or directory named ".." on a server whose file system uses a file or directory named ".." on a server whose file system uses
that name for links to parent directories. that name for links to parent directories.
This error should not be returned due a normalization issue in a This error should not be returned due a normalization issue in a
skipping to change at page 213, line 16 skipping to change at page 214, line 16
server will return the error NFS4ERR_EXIST. server will return the error NFS4ERR_EXIST.
For the directory where the new file object was created, the server For the directory where the new file object was created, the server
returns change_info4 information in cinfo. With the atomic field of returns change_info4 information in cinfo. With the atomic field of
the change_info4 struct, the server will indicate if the before and the change_info4 struct, the server will indicate if the before and
after change attributes were obtained atomically with respect to the after change attributes were obtained atomically with respect to the
file object creation. file object creation.
If the objname is of zero length, NFS4ERR_INVAL will be returned. If the objname is of zero length, NFS4ERR_INVAL will be returned.
The objname is also subject to the normal UTF-8, character support, The objname is also subject to the normal UTF-8, character support,
and name checks. See Section 12.6 for further discussion. and name checks. See Section 12.7 for further discussion.
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 current filehandle is replaced by that of the new object.
The createattrs specifies the initial set of attributes for the The createattrs specifies the initial set of attributes for the
object. The set of attributes may include any writable attribute object. The set of attributes may include any writable attribute
valid for the object type. When the operation is successful, the valid for the object type. When the operation is successful, the
server will return to the client an attribute mask signifying which server will return to the client an attribute mask signifying which
attributes were successfully set for the object. attributes were successfully set for the object.
If createattrs includes neither the owner attribute nor an ACL with If createattrs includes neither the owner attribute nor an ACL with
skipping to change at page 214, line 37 skipping to change at page 215, line 36
nfsstat4 status; nfsstat4 status;
}; };
15.7.4. DESCRIPTION 15.7.4. DESCRIPTION
Purges all of the delegations awaiting recovery for a given client. Purges all of the delegations awaiting recovery for a given client.
This is useful for clients which do not commit delegation information This is useful for clients which do not commit delegation information
to stable storage to indicate that conflicting requests need not be to stable storage to indicate that conflicting requests need not be
delayed by the server awaiting recovery of delegation information. delayed by the server awaiting recovery of delegation information.
This operation in provided to support clients that record delegation This operation is provided to support clients that record delegation
information on stable storage on the client. In this case, information on stable storage on the client. In this case,
DELEGPURGE should be issued immediately after doing delegation DELEGPURGE should be issued immediately after doing delegation
recovery (using CLAIM_DELEGATE_PREV) on all delegations known to the recovery (using CLAIM_DELEGATE_PREV) on all delegations known to the
client. Doing so will notify the server that no additional client. Doing so will notify the server that no additional
delegations for the client will be recovered allowing it to free delegations for the client will be recovered allowing it to free
resources, and avoid delaying other clients who make requests that resources, and avoid delaying other clients who make requests that
conflict with the unrecovered delegations. All client SHOULD use conflict with the unrecovered delegations. All client SHOULD use
DELEGPURGE as part of recovery once it is known that no further DELEGPURGE as part of recovery once it is known that no further
CLAIM_DELEGATE_PREV recovery will be done. This includes clients CLAIM_DELEGATE_PREV recovery will be done. This includes clients
that do not record delegation information on stable storage, who that do not record delegation information on stable storage, who
skipping to change at page 228, line 26 skipping to change at page 229, line 26
component and if the object exists the current filehandle is replaced component and if the object exists the current filehandle is replaced
with the component's filehandle. with the component's filehandle.
If the component cannot be evaluated either because it does not exist If the component cannot be evaluated either because it does not exist
or because the client does not have permission to evaluate the or because the client does not have permission to evaluate the
component, then an error will be returned and the current filehandle component, then an error will be returned and the current filehandle
will be unchanged. will be unchanged.
If the component is of zero length, NFS4ERR_INVAL will be returned. If the component is of zero length, NFS4ERR_INVAL will be returned.
The component is also subject to the normal UTF-8, character support, The component is also subject to the normal UTF-8, character support,
and name checks. See Section 12.6 for further discussion. and name checks. See Section 12.7 for further discussion.
15.15.5. IMPLEMENTATION 15.15.5. IMPLEMENTATION
If the client wants to achieve the effect of a multi-component If the client wants to achieve the effect of a multi-component
lookup, it may construct a COMPOUND request such as (and obtain each lookup, it may construct a COMPOUND request such as (and obtain each
filehandle): filehandle):
PUTFH (directory filehandle) PUTFH (directory filehandle)
LOOKUP "pub" LOOKUP "pub"
GETFH GETFH
skipping to change at page 238, line 24 skipping to change at page 239, line 24
OPEN4_RESULT_CONFIRM indicates that the client MUST execute an OPEN4_RESULT_CONFIRM indicates that the client MUST execute an
OPEN_CONFIRM operation before using the open file. OPEN_CONFIRM operation before using the open file.
OPEN4_RESULT_LOCKTYPE_POSIX indicates the server's file locking OPEN4_RESULT_LOCKTYPE_POSIX indicates the server's file locking
behavior supports the complete set of Posix locking techniques behavior supports the complete set of Posix locking techniques
[fcntl]. From this the client can choose to manage file locking [fcntl]. From this the client can choose to manage file locking
state in a way to handle a mis-match of file locking management. 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. If the component is of zero length, NFS4ERR_INVAL will be returned.
The component is also subject to the normal UTF-8, character support, The component is also subject to the normal UTF-8, character support,
and name checks. See Section 12.6 for further discussion. and name checks. See Section 12.7 for further discussion.
When an OPEN is done and the specified open-owner already has the When an OPEN is done and the specified open-owner already has the
resulting filehandle open, the result is to "OR" together the new resulting filehandle open, the result is to "OR" together the new
share and deny status together with the existing status. In this share and deny status together with the existing status. In this
case, only a single CLOSE need be done, even though multiple OPENs case, only a single CLOSE need be done, even though multiple OPENs
were completed. When such an OPEN is done, checking of share were completed. When such an OPEN is done, checking of share
reservations for the new OPEN proceeds normally, with no exception reservations for the new OPEN proceeds normally, with no exception
for the existing OPEN held by the same owner. In this case, the for the existing OPEN held by the same owner. In this case, the
stateid returned as an "other" field that matches that of the stateid returned as an "other" field that matches that of the
previous open while the "seqid" field is incremented to reflect the previous open while the "seqid" field is incremented to reflect the
skipping to change at page 256, line 20 skipping to change at page 257, line 20
union REMOVE4res switch (nfsstat4 status) { union REMOVE4res switch (nfsstat4 status) {
case NFS4_OK: case NFS4_OK:
REMOVE4resok resok4; REMOVE4resok resok4;
default: default:
void; void;
}; };
15.28.4. DESCRIPTION 15.28.4. DESCRIPTION
The REMOVE operation removes (deletes) a directory entry M named by The REMOVE operation removes (deletes) a directory entry named by
filename from the directory corresponding to the current filehandle. filename from the directory corresponding to the current filehandle.
If the entry in the directory was the last reference to the If the entry in the directory was the last reference to the
corresponding file system object, the object may be destroyed. corresponding file system object, the object may be destroyed.
For the directory where the filename was removed, the server returns For the directory where the filename was removed, the server returns
change_info4 information in cinfo. With the atomic field of the change_info4 information in cinfo. With the atomic field of the
change_info4 struct, the server will indicate if the before and after change_info4 struct, the server will indicate if the before and after
change attributes were obtained atomically with respect to the change attributes were obtained atomically with respect to the
removal. removal.
If the target is of zero length, NFS4ERR_INVAL will be returned. The If the target is of zero length, NFS4ERR_INVAL will be returned. The
target is also subject to the normal UTF-8, character support, and target is also subject to the normal UTF-8, character support, and
name checks. See Section 12.6 for further discussion. name checks. See Section 12.7 for further discussion.
On success, the current filehandle retains its value. On success, the current filehandle retains its value.
15.28.5. IMPLEMENTATION 15.28.5. IMPLEMENTATION
NFSv3 required a different operator RMDIR for directory removal and NFSv3 required a different operator RMDIR for directory removal and
REMOVE for non-directory removal. This allowed clients to skip REMOVE for non-directory removal. This allowed clients to skip
checking the file type when being passed a non-directory delete checking the file type when being passed a non-directory delete
system call (e.g., unlink() [unlink] in POSIX) to remove a directory, system call (e.g., unlink() [unlink] in POSIX) to remove a directory,
as well as the converse (e.g., a rmdir() on a non-directory) because as well as the converse (e.g., a rmdir() on a non-directory) because
skipping to change at page 259, line 7 skipping to change at page 260, line 7
struct, the server will indicate if the before and after change struct, the server will indicate if the before and after change
attributes were obtained atomically with respect to the rename. attributes were obtained atomically with respect to the rename.
If the oldname refers to a named attribute and the saved and current If the oldname refers to a named attribute and the saved and current
filehandles refer to different file system objects, the server will filehandles refer to different file system objects, the server will
return NFS4ERR_XDEV just as if the saved and current filehandles return NFS4ERR_XDEV just as if the saved and current filehandles
represented directories on different file systems. represented directories on different file systems.
If the oldname or newname is of zero length, NFS4ERR_INVAL will be If the oldname or newname is of zero length, NFS4ERR_INVAL will be
returned. The oldname and newname are also subject to the normal returned. The oldname and newname are also subject to the normal
UTF-8, character support, and name checks. See Section 12.6 for UTF-8, character support, and name checks. See Section 12.7 for
further discussion. further discussion.
15.29.5. IMPLEMENTATION 15.29.5. IMPLEMENTATION
The RENAME operation must be atomic to the client. The statement The RENAME operation must be atomic to the client. The statement
"source and target directories must reside on the same file system on "source and target directories must reside on the same file system on
the server" means that the fsid fields in the attributes for the the server" means that the fsid fields in the attributes for the
directories are the same. If they reside on different file systems, directories are the same. If they reside on different file systems,
the error, NFS4ERR_XDEV, is returned. the error, NFS4ERR_XDEV, is returned.
 End of changes. 43 change blocks. 
161 lines changed or deleted 224 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/