Found wdiff, but it reported no recognisable version. Falling back to builtin diff colouring... Diff: draft-pre-ch-18-lock.txt - draft-ietf-nfsv4-minorversion1-22.txt
 draft-pre-ch-18-lock.txt   draft-ietf-nfsv4-minorversion1-22.txt 
NFSv4 S. Shepler NFSv4 S. Shepler
Internet-Draft M. Eisler Internet-Draft M. Eisler
Intended status: Standards Track D. Noveck Intended status: Standards Track D. Noveck
Expires: October 10, 2008 Editors Expires: October 12, 2008 Editors
April 8, 2008 April 10, 2008
NFS Version 4 Minor Version 1 NFS Version 4 Minor Version 1
draft-ietf-nfsv4-minorversion1-22.txt draft-ietf-nfsv4-minorversion1-22.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 10, 2008. This Internet-Draft will expire on October 12, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This Internet-Draft describes NFS version 4 minor version one, This Internet-Draft describes NFS version 4 minor version one,
including features retained from the base protocol and protocol including features retained from the base protocol and protocol
extensions made subsequently. Major extensions introduced in NFS extensions made subsequently. Major extensions introduced in NFS
skipping to change at page 8, line 22 skipping to change at page 8, line 22
18.2. Operation 4: CLOSE - Close File . . . . . . . . . . . . 396 18.2. Operation 4: CLOSE - Close File . . . . . . . . . . . . 396
18.3. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 397 18.3. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 397
18.4. Operation 6: CREATE - Create a Non-Regular File Object . 400 18.4. Operation 6: CREATE - Create a Non-Regular File Object . 400
18.5. Operation 7: DELEGPURGE - Purge Delegations Awaiting 18.5. Operation 7: DELEGPURGE - Purge Delegations Awaiting
Recovery . . . . . . . . . . . . . . . . . . . . . . . . 403 Recovery . . . . . . . . . . . . . . . . . . . . . . . . 403
18.6. Operation 8: DELEGRETURN - Return Delegation . . . . . . 404 18.6. Operation 8: DELEGRETURN - Return Delegation . . . . . . 404
18.7. Operation 9: GETATTR - Get Attributes . . . . . . . . . 404 18.7. Operation 9: GETATTR - Get Attributes . . . . . . . . . 404
18.8. Operation 10: GETFH - Get Current Filehandle . . . . . . 406 18.8. Operation 10: GETFH - Get Current Filehandle . . . . . . 406
18.9. Operation 11: LINK - Create Link to a File . . . . . . . 407 18.9. Operation 11: LINK - Create Link to a File . . . . . . . 407
18.10. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 410 18.10. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 410
18.11. Operation 13: LOCKT - Test For Lock . . . . . . . . . . 413 18.11. Operation 13: LOCKT - Test For Lock . . . . . . . . . . 414
18.12. Operation 14: LOCKU - Unlock File . . . . . . . . . . . 415 18.12. Operation 14: LOCKU - Unlock File . . . . . . . . . . . 415
18.13. Operation 15: LOOKUP - Lookup Filename . . . . . . . . . 416 18.13. Operation 15: LOOKUP - Lookup Filename . . . . . . . . . 417
18.14. Operation 16: LOOKUPP - Lookup Parent Directory . . . . 418 18.14. Operation 16: LOOKUPP - Lookup Parent Directory . . . . 418
18.15. Operation 17: NVERIFY - Verify Difference in 18.15. Operation 17: NVERIFY - Verify Difference in
Attributes . . . . . . . . . . . . . . . . . . . . . . . 419 Attributes . . . . . . . . . . . . . . . . . . . . . . . 420
18.16. Operation 18: OPEN - Open a Regular File . . . . . . . . 420 18.16. Operation 18: OPEN - Open a Regular File . . . . . . . . 421
18.17. Operation 19: OPENATTR - Open Named Attribute 18.17. Operation 19: OPENATTR - Open Named Attribute
Directory . . . . . . . . . . . . . . . . . . . . . . . 439 Directory . . . . . . . . . . . . . . . . . . . . . . . 440
18.18. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 440 18.18. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 441
18.19. Operation 22: PUTFH - Set Current Filehandle . . . . . . 442 18.19. Operation 22: PUTFH - Set Current Filehandle . . . . . . 442
18.20. Operation 23: PUTPUBFH - Set Public Filehandle . . . . . 442 18.20. Operation 23: PUTPUBFH - Set Public Filehandle . . . . . 443
18.21. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 444 18.21. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 445
18.22. Operation 25: READ - Read from File . . . . . . . . . . 445 18.22. Operation 25: READ - Read from File . . . . . . . . . . 445
18.23. Operation 26: READDIR - Read Directory . . . . . . . . . 447 18.23. Operation 26: READDIR - Read Directory . . . . . . . . . 448
18.24. Operation 27: READLINK - Read Symbolic Link . . . . . . 451 18.24. Operation 27: READLINK - Read Symbolic Link . . . . . . 452
18.25. Operation 28: REMOVE - Remove File System Object . . . . 452 18.25. Operation 28: REMOVE - Remove File System Object . . . . 453
18.26. Operation 29: RENAME - Rename Directory Entry . . . . . 454 18.26. Operation 29: RENAME - Rename Directory Entry . . . . . 455
18.27. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 458 18.27. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 459
18.28. Operation 32: SAVEFH - Save Current Filehandle . . . . . 459 18.28. Operation 32: SAVEFH - Save Current Filehandle . . . . . 460
18.29. Operation 33: SECINFO - Obtain Available Security . . . 460 18.29. Operation 33: SECINFO - Obtain Available Security . . . 461
18.30. Operation 34: SETATTR - Set Attributes . . . . . . . . . 463 18.30. Operation 34: SETATTR - Set Attributes . . . . . . . . . 464
18.31. Operation 37: VERIFY - Verify Same Attributes . . . . . 465 18.31. Operation 37: VERIFY - Verify Same Attributes . . . . . 466
18.32. Operation 38: WRITE - Write to File . . . . . . . . . . 466 18.32. Operation 38: WRITE - Write to File . . . . . . . . . . 467
18.33. Operation 40: BACKCHANNEL_CTL - Backchannel control . . 471 18.33. Operation 40: BACKCHANNEL_CTL - Backchannel control . . 472
18.34. Operation 41: BIND_CONN_TO_SESSION . . . . . . . . . . . 472 18.34. Operation 41: BIND_CONN_TO_SESSION . . . . . . . . . . . 473
18.35. Operation 42: EXCHANGE_ID - Instantiate Client ID . . . 475 18.35. Operation 42: EXCHANGE_ID - Instantiate Client ID . . . 476
18.36. Operation 43: CREATE_SESSION - Create New Session and 18.36. Operation 43: CREATE_SESSION - Create New Session and
Confirm Client ID . . . . . . . . . . . . . . . . . . . 491 Confirm Client ID . . . . . . . . . . . . . . . . . . . 492
18.37. Operation 44: DESTROY_SESSION - Destroy existing 18.37. Operation 44: DESTROY_SESSION - Destroy existing
session . . . . . . . . . . . . . . . . . . . . . . . . 501 session . . . . . . . . . . . . . . . . . . . . . . . . 502
18.38. Operation 45: FREE_STATEID - Free stateid with no 18.38. Operation 45: FREE_STATEID - Free stateid with no
locks . . . . . . . . . . . . . . . . . . . . . . . . . 503 locks . . . . . . . . . . . . . . . . . . . . . . . . . 504
18.39. Operation 46: GET_DIR_DELEGATION - Get a directory 18.39. Operation 46: GET_DIR_DELEGATION - Get a directory
delegation . . . . . . . . . . . . . . . . . . . . . . . 504 delegation . . . . . . . . . . . . . . . . . . . . . . . 505
18.40. Operation 47: GETDEVICEINFO - Get Device Information . . 508 18.40. Operation 47: GETDEVICEINFO - Get Device Information . . 509
18.41. Operation 48: GETDEVICELIST - Get All Device Mappings 18.41. Operation 48: GETDEVICELIST - Get All Device Mappings
for a File System . . . . . . . . . . . . . . . . . . . 510 for a File System . . . . . . . . . . . . . . . . . . . 511
18.42. Operation 49: LAYOUTCOMMIT - Commit writes made using 18.42. Operation 49: LAYOUTCOMMIT - Commit writes made using
a layout . . . . . . . . . . . . . . . . . . . . . . . . 512 a layout . . . . . . . . . . . . . . . . . . . . . . . . 513
18.43. Operation 50: LAYOUTGET - Get Layout Information . . . . 515 18.43. Operation 50: LAYOUTGET - Get Layout Information . . . . 516
18.44. Operation 51: LAYOUTRETURN - Release Layout 18.44. Operation 51: LAYOUTRETURN - Release Layout
Information . . . . . . . . . . . . . . . . . . . . . . 519 Information . . . . . . . . . . . . . . . . . . . . . . 520
18.45. Operation 52: SECINFO_NO_NAME - Get Security on 18.45. Operation 52: SECINFO_NO_NAME - Get Security on
Unnamed Object . . . . . . . . . . . . . . . . . . . . . 524 Unnamed Object . . . . . . . . . . . . . . . . . . . . . 525
18.46. Operation 53: SEQUENCE - Supply per-procedure 18.46. Operation 53: SEQUENCE - Supply per-procedure
sequencing and control . . . . . . . . . . . . . . . . . 525 sequencing and control . . . . . . . . . . . . . . . . . 526
18.47. Operation 54: SET_SSV - Update SSV for a Client ID . . . 531 18.47. Operation 54: SET_SSV - Update SSV for a Client ID . . . 532
18.48. Operation 55: TEST_STATEID - Test stateids for 18.48. Operation 55: TEST_STATEID - Test stateids for
validity . . . . . . . . . . . . . . . . . . . . . . . . 533 validity . . . . . . . . . . . . . . . . . . . . . . . . 534
18.49. Operation 56: WANT_DELEGATION - Request Delegation . . . 535 18.49. Operation 56: WANT_DELEGATION - Request Delegation . . . 536
18.50. Operation 57: DESTROY_CLIENTID - Destroy existing 18.50. Operation 57: DESTROY_CLIENTID - Destroy existing
client ID . . . . . . . . . . . . . . . . . . . . . . . 539 client ID . . . . . . . . . . . . . . . . . . . . . . . 540
18.51. Operation 58: RECLAIM_COMPLETE - Indicates Reclaims 18.51. Operation 58: RECLAIM_COMPLETE - Indicates Reclaims
Finished . . . . . . . . . . . . . . . . . . . . . . . . 539 Finished . . . . . . . . . . . . . . . . . . . . . . . . 540
18.52. Operation 10044: ILLEGAL - Illegal operation . . . . . . 542 18.52. Operation 10044: ILLEGAL - Illegal operation . . . . . . 543
19. NFSv4.1 Callback Procedures . . . . . . . . . . . . . . . . . 542 19. NFSv4.1 Callback Procedures . . . . . . . . . . . . . . . . . 543
19.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 543 19.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 544
19.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 543 19.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 544
20. NFSv4.1 Callback Operations . . . . . . . . . . . . . . . . . 547 20. NFSv4.1 Callback Operations . . . . . . . . . . . . . . . . . 548
20.1. Operation 3: CB_GETATTR - Get Attributes . . . . . . . . 547 20.1. Operation 3: CB_GETATTR - Get Attributes . . . . . . . . 548
20.2. Operation 4: CB_RECALL - Recall an Open Delegation . . . 548 20.2. Operation 4: CB_RECALL - Recall an Open Delegation . . . 549
20.3. Operation 5: CB_LAYOUTRECALL - Recall Layout from 20.3. Operation 5: CB_LAYOUTRECALL - Recall Layout from
Client . . . . . . . . . . . . . . . . . . . . . . . . . 549 Client . . . . . . . . . . . . . . . . . . . . . . . . . 550
20.4. Operation 6: CB_NOTIFY - Notify directory changes . . . 553 20.4. Operation 6: CB_NOTIFY - Notify directory changes . . . 554
20.5. Operation 7: CB_PUSH_DELEG - Offer Delegation to 20.5. Operation 7: CB_PUSH_DELEG - Offer Delegation to
Client . . . . . . . . . . . . . . . . . . . . . . . . . 557 Client . . . . . . . . . . . . . . . . . . . . . . . . . 558
20.6. Operation 8: CB_RECALL_ANY - Keep any N delegations . . 558 20.6. Operation 8: CB_RECALL_ANY - Keep any N delegations . . 559
20.7. Operation 9: CB_RECALLABLE_OBJ_AVAIL - Signal 20.7. Operation 9: CB_RECALLABLE_OBJ_AVAIL - Signal
Resources for Recallable Objects . . . . . . . . . . . . 560 Resources for Recallable Objects . . . . . . . . . . . . 561
20.8. Operation 10: CB_RECALL_SLOT - change flow control 20.8. Operation 10: CB_RECALL_SLOT - change flow control
limits . . . . . . . . . . . . . . . . . . . . . . . . . 561 limits . . . . . . . . . . . . . . . . . . . . . . . . . 562
20.9. Operation 11: CB_SEQUENCE - Supply backchannel 20.9. Operation 11: CB_SEQUENCE - Supply backchannel
sequencing and control . . . . . . . . . . . . . . . . . 562 sequencing and control . . . . . . . . . . . . . . . . . 563
20.10. Operation 12: CB_WANTS_CANCELLED - Cancel Pending 20.10. Operation 12: CB_WANTS_CANCELLED - Cancel Pending
Delegation Wants . . . . . . . . . . . . . . . . . . . . 564 Delegation Wants . . . . . . . . . . . . . . . . . . . . 565
20.11. Operation 13: CB_NOTIFY_LOCK - Notify of possible 20.11. Operation 13: CB_NOTIFY_LOCK - Notify of possible
lock availability . . . . . . . . . . . . . . . . . . . 565 lock availability . . . . . . . . . . . . . . . . . . . 566
20.12. Operation 14: CB_NOTIFY_DEVICEID - Notify device ID 20.12. Operation 14: CB_NOTIFY_DEVICEID - Notify device ID
changes . . . . . . . . . . . . . . . . . . . . . . . . 567 changes . . . . . . . . . . . . . . . . . . . . . . . . 568
20.13. Operation 10044: CB_ILLEGAL - Illegal Callback 20.13. Operation 10044: CB_ILLEGAL - Illegal Callback
Operation . . . . . . . . . . . . . . . . . . . . . . . 569 Operation . . . . . . . . . . . . . . . . . . . . . . . 570
21. Security Considerations . . . . . . . . . . . . . . . . . . . 569 21. Security Considerations . . . . . . . . . . . . . . . . . . . 570
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 571 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 572
22.1. Named Attribute Definitions . . . . . . . . . . . . . . 571 22.1. Named Attribute Definitions . . . . . . . . . . . . . . 572
22.2. ONC RPC Network Identifiers (netids) . . . . . . . . . . 571 22.2. ONC RPC Network Identifiers (netids) . . . . . . . . . . 572
22.3. Defining New Notifications . . . . . . . . . . . . . . . 572 22.3. Defining New Notifications . . . . . . . . . . . . . . . 573
22.4. Defining New Layout Types . . . . . . . . . . . . . . . 572 22.4. Defining New Layout Types . . . . . . . . . . . . . . . 573
22.5. Path Variable Definitions . . . . . . . . . . . . . . . 574 22.5. Path Variable Definitions . . . . . . . . . . . . . . . 575
22.5.1. Path Variable Values . . . . . . . . . . . . . . . . 574 22.5.1. Path Variable Values . . . . . . . . . . . . . . . . 575
22.5.2. Path Variable Names . . . . . . . . . . . . . . . . 574 22.5.2. Path Variable Names . . . . . . . . . . . . . . . . 575
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 574 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 575
23.1. Normative References . . . . . . . . . . . . . . . . . . 574 23.1. Normative References . . . . . . . . . . . . . . . . . . 575
23.2. Informative References . . . . . . . . . . . . . . . . . 576 23.2. Informative References . . . . . . . . . . . . . . . . . 577
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 578 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 579
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 580 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 581
Intellectual Property and Copyright Statements . . . . . . . . . 581 Intellectual Property and Copyright Statements . . . . . . . . . 582
1. Introduction 1. Introduction
1.1. The NFS Version 4 Minor Version 1 Protocol 1.1. The NFS Version 4 Minor Version 1 Protocol
The NFS version 4 minor version 1 (NFSv4.1) protocol is the second The NFS version 4 minor version 1 (NFSv4.1) protocol is the second
minor version of the NFS version 4 (NFSv4) protocol. The first minor minor version of the NFS version 4 (NFSv4) protocol. The first minor
version, NFSv4.0 is described in [21]. It generally follows the version, NFSv4.0 is described in [21]. It generally follows the
guidelines for minor versioning model listed in Section 10 of RFC guidelines for minor versioning model listed in Section 10 of RFC
3530. However, it diverges from guidelines 11 ("a client and server 3530. However, it diverges from guidelines 11 ("a client and server
skipping to change at page 117, line 43 skipping to change at page 117, line 43
This attribute allows one to 64 administrative holds, one hold per This attribute allows one to 64 administrative holds, one hold per
bit on the attribute. If retention_hold is not zero, then the file bit on the attribute. If retention_hold is not zero, then the file
MUST NOT be deleted, renamed, or modified, even if the duration on MUST NOT be deleted, renamed, or modified, even if the duration on
enabled event or non-event-based retention has been reached. The enabled event or non-event-based retention has been reached. The
server MAY restrict the modification of retention_hold on the basis server MAY restrict the modification of retention_hold on the basis
of the ACE4_WRITE_RETENTION_HOLD ACL permission. The enabling of of the ACE4_WRITE_RETENTION_HOLD ACL permission. The enabling of
administration retention holds does not prevent the enabling of administration retention holds does not prevent the enabling of
event-based or non-event-based retention. event-based or non-event-based retention.
If the principal attempting to change retention_hold or not have If the principal attempting to change retention_hold does not have
ACE4_WRITE_RETENTION_HOLD permissions, the attempt MUST fail with ACE4_WRITE_RETENTION_HOLD permissions, the attempt MUST fail with
NFS4ERR_ACCESS. NFS4ERR_ACCESS.
6. Access Control Attributes 6. Access Control Attributes
Access Control Lists (ACLs) are file attributes that specify fine Access Control Lists (ACLs) are file attributes that specify fine
grained access control. This chapter covers the "acl", "dacl", grained access control. This chapter covers the "acl", "dacl",
"sacl", "aclsupport", "mode", "mode_set_masked" file attributes, and "sacl", "aclsupport", "mode", "mode_set_masked" file attributes, and
their interactions. Note that file attributes may apply to any file their interactions. Note that file attributes may apply to any file
system object. system object.
skipping to change at page 411, line 30 skipping to change at page 411, line 30
LOCK4resok resok4; LOCK4resok resok4;
case NFS4ERR_DENIED: case NFS4ERR_DENIED:
LOCK4denied denied; LOCK4denied denied;
default: default:
void; void;
}; };
18.10.3. DESCRIPTION 18.10.3. DESCRIPTION
The LOCK operation requests a byte-range lock for the byte range The LOCK operation requests a byte-range lock for the byte range
specified by the offset and length parameters. The lock type is also specified by the offset and length parameters, and lock type
specified to be one of the nfs_lock_type4s. If this is a reclaim specified in the locktype parameter. If this is a reclaim request,
request, the reclaim parameter will be TRUE. the reclaim parameter will be TRUE.
Bytes in a file may be locked even if those bytes are not currently 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 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 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, a length field equal to NFS4_UINT64_MAX. The server MUST return
or if a length which is not all bits set to one is specified, and NFS4ERR_INVAL under the following combinations of length and offset:
length when added to the offset exceeds the maximum 64-bit unsigned
integer value, the error NFS4ERR_INVAL will result.
32 bit servers are servers that support locking for byte offsets that o Length is equal to zero.
fit within 32 bits (i.e. less than or equal to 0xFFFFFFFF). If the
client specifies a range that overlaps one or more bytes beyond o Length is not equal to NFS4_UINT64_MAX, and the sum of length and
offset 0xFFFFFFFF, but does not end at the maximum 64 bit offset offset exceeds NFS4_UINT64_MAX.
(i.e. 0xFFFFFFFFFFFFFFFF), such a 32-bit server MUST return the error
NFS4ERR_BAD_RANGE. 32-bit servers are servers that support locking for byte offsets that
fit within 32 bits (i.e. less than or equal to NFS4_UINT32_MAX). If
the client specifies a range that overlaps one or more bytes beyond
offset NFS4_UINT32_MAX, but does not end at offset NFS4_UINT64_MAX
such a 32-bit server MUST return the error NFS4ERR_BAD_RANGE.
If the server returns NFS4ERR_DENIED, owner, offset, and length of a If the server returns NFS4ERR_DENIED, owner, offset, and length of a
conflicting lock are returned. conflicting lock are returned.
The locker argument specifies the lock-owner that is associated with The locker argument specifies the lock-owner that is associated with
the LOCK request. The locker4 structure is a switched union that the LOCK request. The locker4 structure is a switched union that
indicates whether the client has already created byte-range locking indicates whether the client has already created byte-range locking
state associated with the current open file and lock-owner. In the state associated with the current open file and lock-owner. In the
case in which it has, the argument is just a stateid for the set of case in which it has, the argument is just a stateid representing the
locks associated with that open file and lock-owner, together with a set of locks associated with that open file and lock-owner, together
lock_seqid value which MAY be any value and MUST be ignored by the with a lock_seqid value which MAY be any value and MUST be ignored by
server. In the case where no such state has been established, or the the server. In the case where no byte-range locking state has been
client does not have the stateid available, the argument contains the established, or the client does not have the stateid available, the
stateid of the open file with which this lock is to be associated, argument contains the stateid of the open file with which this lock
together with the lock-owner with which the lock is to be associated. is to be associated, together with the lock-owner with which the lock
The open_to_lock_owner case covers the very first lock done by a is to be associated. The open_to_lock_owner case covers the very
lock-owner for a given open file and offers a method to use the first lock done by a lock-owner for a given open file and offers a
established state of the open_stateid to transition to the use of a method to use the established state of the open_stateid to transition
lock stateid. to the use of a lock stateid.
The client field of lock_owner, and all seqid values in the arguments The following fields of the locker parameter MAY be set to any value
MAY be any value and MUST be ignored by the server. The client ID by the client and MUST be ignored by the server:
with which all owners and stateids are associated is the client ID
associated with the session on which the request was sent. The o The clientid field of the lock_owner field of the open_owner field
client ID appearing in a LOCK4denied structure is the actual client (locker.open_owner.lock_owner.clientid). The reason the server
associated with the conflicting lock, whether this is the client ID MUST ignore the clientid field is that the server MUST derive the
associated with the current session, or a different one. client ID from the sessionid from the SEQUENCE operation of the
COMPOUND request.
o The open_seqid and lock_seqid fields of the open_owner field
(locker.open_owner.open_seqid and locker.open_owner.lock_seqid).
o The lock_seqid field of the lock_owner field
(locker.lock_owner.lock_seqid).
Note that the client ID appearing in a LOCK4denied structure is the
actual client associated with the conflicting lock, whether this is
the client ID associated with the current session, or a different
one. Thus if the server returns NFS4ERR_DENIED, it MUST set clientid
of the owner field of the denied field.
If the current filehandle is not an ordinary file, an error will be If the current filehandle is not an ordinary file, an error will be
returned to the client. In the case that the current filehandle returned to the client. In the case that the current filehandle
represents an object of type NF4DIR, NFS4ERR_ISDIR is returned. if represents an object of type NF4DIR, NFS4ERR_ISDIR is returned. if
the current filehandle designates a symbolic link, NFS4ERR_SYMLINK is the current filehandle designates a symbolic link, NFS4ERR_SYMLINK is
returned. In all other cases, NFS4ERR_WRONG_TYPE is returned. returned. In all other cases, NFS4ERR_WRONG_TYPE is returned.
On success, the current filehandle retains its value. On success, the current filehandle retains its value.
18.10.4. IMPLEMENTATION 18.10.4. IMPLEMENTATION
skipping to change at page 413, line 29 skipping to change at page 413, line 46
When a client holds a write delegation, the client holding that When a client holds a write delegation, the client holding that
delegation is assured that there are no opens by other clients. delegation is assured that there are no opens by other clients.
Thus, there can be no conflicting LOCK requests from such clients. Thus, there can be no conflicting LOCK requests from such clients.
Therefore, the client may be handling locking requests locally, Therefore, the client may be handling locking requests locally,
without doing LOCK operations on the server. If it does that, it without doing LOCK operations on the server. If it does that, it
must be prepared to update the lock status on the server, by doing must be prepared to update the lock status on the server, by doing
appropriate LOCK and LOCKU requests before returning the delegation. appropriate LOCK and LOCKU requests before returning the delegation.
When one or more clients hold read delegations, any LOCK request When one or more clients hold read delegations, any LOCK request
where the server is implementing mandatory locking semantics, must where the server is implementing mandatory locking semantics, MUST
result in the recall of all such delegations. The LOCK request may result in the recall of all such delegations. The LOCK request may
not be granted until all such delegations are return or revoked. not be granted until all such delegations are return or revoked.
Except where this happens very quickly, one or more NFS4ERR_DELAY Except where this happens very quickly, one or more NFS4ERR_DELAY
errors will be returned to requests made while delegation remains errors will be returned to requests made while the delegation remains
outstanding. outstanding.
18.11. Operation 13: LOCKT - Test For Lock 18.11. Operation 13: LOCKT - Test For Lock
18.11.1. ARGUMENTS 18.11.1. ARGUMENTS
struct LOCKT4args { struct LOCKT4args {
/* CURRENT_FH: file */ /* CURRENT_FH: file */
nfs_lock_type4 locktype; nfs_lock_type4 locktype;
offset4 offset; offset4 offset;
skipping to change at page 414, line 33 skipping to change at page 414, line 45
client ID. If no lock is held, nothing other than NFS4_OK is client ID. If no lock is held, nothing other than NFS4_OK is
returned. Lock types READ_LT and READW_LT are processed in the same 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 way in that a conflicting lock test is done without regard to
blocking or non-blocking. The same is true for WRITE_LT and blocking or non-blocking. The same is true for WRITE_LT and
WRITEW_LT. WRITEW_LT.
The ranges are specified as for LOCK. The NFS4ERR_INVAL and The ranges are specified as for LOCK. The NFS4ERR_INVAL and
NFS4ERR_BAD_RANGE errors are returned under the same circumstances as NFS4ERR_BAD_RANGE errors are returned under the same circumstances as
for LOCK. for LOCK.
The client ID field of the owner should be specified as zero. The The clientid field of the owner MAY be set to any value by the client
client ID used for ownership comparisons is that associated with the and MUST be ignored by the server. The reason the server MUST ignore
session on which the request is sent. If the client ID field is the clientid field is that the server MUST derive the client ID from
other than zero, the server MUST return the error NFS4ERR_INVAL. the sessionid from the SEQUENCE operation of the COMPOUND request.
If the current filehandle is not an ordinary file, an error will be If the current filehandle is not an ordinary file, an error will be
returned to the client. In the case that the current filehandle returned to the client. In the case that the current filehandle
represents an object of type NF4DIR, NFS4ERR_ISDIR is returned. if represents an object of type NF4DIR, NFS4ERR_ISDIR is returned. if
the current filehandle designates a symbolic link, NFS4ERR_SYMLINK is the current filehandle designates a symbolic link, NFS4ERR_SYMLINK is
returned. In all other cases, NFS4ERR_WRONG_TYPE is returned. returned. In all other cases, NFS4ERR_WRONG_TYPE is returned.
On success, the current filehandle retains its value. On success, the current filehandle retains its value.
18.11.4. IMPLEMENTATION 18.11.4. IMPLEMENTATION
If the server is unable to determine the exact offset and length of If the server is unable to determine the exact offset and length of
the conflicting lock, the same offset and length that were provided the conflicting lock, the same offset and length that were provided
in the arguments should be returned in the denied results. in the arguments should be returned in the denied results.
LOCKT uses a lock_owner4 rather a stateid4, as is used in LOCK to 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 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 the file to test for the existence of a lock, so a stateid might not
available. be available.
The test for conflicting locks should exclude locks for the current The test for conflicting locks should exclude locks for the current
lock-owner. Note that since such locks are not examined the possible lock-owner, but the NFSv4.1 specification is flexible in this regard.
existence of overlapping ranges may not affect the results of LOCKT. Note that if such locks are not examined, the possible existence of
If the server does examine locks that match the lock-owner for the overlapping ranges might not affect the results of LOCKT, but might
purpose of range checking, NFS4ERR_LOCK_RANGE may be returned.. In affect the results of LOCK. If the server does examine locks that
the event that it returns NFS4_OK, clients may do a LOCK and receive match the lock-owner for the purpose of range checking,
NFS4ERR_LOCK_RANGE on the LOCK request because of the flexibility NFS4ERR_LOCK_RANGE may be returned in the rely to LOCKT. In the
provided to the server. event the server returns NFS4_OK in the reply to LOCKT, it is
possible when the client sends LOCK request, the server will reject
it with NFS4ERR_LOCK_RANGE due to the flexibility the NFSv4.1
specification allows the server.
When a client holds a write delegation, it may choose (See When a client holds a write delegation, it may choose (see
Section 18.10.4) to handle LOCK requests locally. In such a case, Section 18.10.4) to handle LOCK requests locally. In such a case,
LOCKT requests will similarly be handled locally. LOCKT requests will similarly be handled locally.
18.12. Operation 14: LOCKU - Unlock File 18.12. Operation 14: LOCKU - Unlock File
18.12.1. ARGUMENTS 18.12.1. ARGUMENTS
struct LOCKU4args { struct LOCKU4args {
/* CURRENT_FH: file */ /* CURRENT_FH: file */
nfs_lock_type4 locktype; nfs_lock_type4 locktype;
skipping to change at page 419, line 5 skipping to change at page 419, line 21
18.14.3. DESCRIPTION 18.14.3. DESCRIPTION
The current filehandle is assumed to refer to a regular directory or The current filehandle is assumed to refer to a regular directory or
a named attribute directory. LOOKUPP assigns the filehandle for its a named attribute directory. LOOKUPP assigns the filehandle for its
parent directory to be the current filehandle. If there is no parent parent directory to be the current filehandle. If there is no parent
directory an NFS4ERR_NOENT error must be returned. Therefore, directory an NFS4ERR_NOENT error must be returned. Therefore,
NFS4ERR_NOENT will be returned by the server when the current NFS4ERR_NOENT will be returned by the server when the current
filehandle is at the root or top of the server's file tree. filehandle is at the root or top of the server's file tree.
As for LOOKUP, LOOKUPP will also cross mountpoints. As is the case with LOOKUP, LOOKUPP will also cross mountpoints.
If the current filehandle is not a directory or named attribute If the current filehandle is not a directory or named attribute
directory, the error NFS4ERR_NOTDIR is returned. directory, the error NFS4ERR_NOTDIR is returned.
If the requester's security flavor does not match that configured for If the requester's security flavor does not match that configured for
the parent directory, then the server SHOULD return NFS4ERR_WRONGSEC the parent directory, then the server SHOULD return NFS4ERR_WRONGSEC
(a future minor revision of NFSv4 may upgrade this to MUST) in the (a future minor revision of NFSv4 may upgrade this to MUST) in the
LOOKUPP response. However, if the server does so, it MUST support LOOKUPP response. However, if the server does so, it MUST support
the new SECINFO_NO_NAME operation, so that the client can gracefully the SECINFO_NO_NAME operation (Section 18.45), so that the client can
determine the correct security flavor. See the discussion of the gracefully determine the correct security flavor.
SECINFO_NO_NAME operation for a description.
If the current filehandle is a named attribute directory that is If the current filehandle is a named attribute directory that is
associated with a file system object via OPENATTR (i.e. not a sub- associated with a file system object via OPENATTR (i.e. not a sub-
directory of a named attribute directory) LOOKUPP SHOULD return the directory of a named attribute directory) LOOKUPP SHOULD return the
filehandle of the associated file system object. filehandle of the associated file system object.
18.14.4. IMPLEMENTATION 18.14.4. IMPLEMENTATION
An issue to note is upward navigation from named attribute An issue to note is upward navigation from named attribute
directories. The named attribute directories are essentially directories. The named attribute directories are essentially
skipping to change at page 420, line 9 skipping to change at page 420, line 24
18.15.2. RESULTS 18.15.2. RESULTS
struct NVERIFY4res { struct NVERIFY4res {
nfsstat4 status; nfsstat4 status;
}; };
18.15.3. DESCRIPTION 18.15.3. DESCRIPTION
This operation is used to prefix a sequence of operations to be This operation is used to prefix a sequence of operations to be
performed if one or more attributes have changed on some file system performed if one or more attributes have changed on some file system
object. If all the attributes match then the error NFS4ERR_SAME must object. If all the attributes match then the error NFS4ERR_SAME MUST
be returned. be returned.
On success, the current filehandle retains its value. On success, the current filehandle retains its value.
18.15.4. IMPLEMENTATION 18.15.4. IMPLEMENTATION
This operation is useful as a cache validation operator. If the This operation is useful as a cache validation operator. If the
object to which the attributes belong has changed then the following object to which the attributes belong has changed then the following
operations may obtain new data associated with that object. For operations may obtain new data associated with that object. For
instance, to check if a file has been changed and obtain new data if instance, to check if a file has been changed and obtain new data if
it has: it has:
PUTFH (public) SEQUENCE
LOOKUP "foobar" PUTFH fh
NVERIFY attrbits attrs NVERIFY attrbits attrs
READ 0 32767 READ 0 32767
Contrast this with NFSv3, which would first send a GETATTR in one
request/reply round trip, and then if attributes indicated that the
client's cache was stale, then send a READ in another request/reply
round trip.
In the case that a RECOMMENDED attribute is specified in the NVERIFY In the case that a RECOMMENDED attribute is specified in the NVERIFY
operation and the server does not support that attribute for the file operation and the server does not support that attribute for the file
system object, the error NFS4ERR_ATTRNOTSUPP is returned to the system object, the error NFS4ERR_ATTRNOTSUPP is returned to the
client. client.
When the attribute rdattr_error or any write-only attribute (e.g. When the attribute rdattr_error or any write-only attribute (e.g.
time_modify_set) is specified, the error NFS4ERR_INVAL is returned to time_modify_set) is specified, the error NFS4ERR_INVAL is returned to
the client. the client.
18.16. Operation 18: OPEN - Open a Regular File 18.16. Operation 18: OPEN - Open a Regular File
skipping to change at page 427, line 37 skipping to change at page 428, line 10
creation is via the openhow parameter. The openhow parameter creation is via the openhow parameter. The openhow parameter
consists of a switched union (data type opengflag4), which switches consists of a switched union (data type opengflag4), which switches
on the value of opentype (OPEN4_NOCREATE or OPEN4_CREATE). If on the value of opentype (OPEN4_NOCREATE or OPEN4_CREATE). If
OPEN4_CREATE is specified, this leads to another switched union (data OPEN4_CREATE is specified, this leads to another switched union (data
type createhow4) that supports four cases of creation methods: type createhow4) that supports four cases of creation methods:
UNCHECKED4, GUARDED4, EXCLUSIVE4, or EXCLUSIVE4_1. If opentype is UNCHECKED4, GUARDED4, EXCLUSIVE4, or EXCLUSIVE4_1. If opentype is
OPEN4_CREATE, then the claim field of the claim field (sic) MUST be OPEN4_CREATE, then the claim field of the claim field (sic) MUST be
one of CLAIM_NULL, CLAIM_DELEGATE_CUR, or CLAIM_DELEGATE_PREV, one of CLAIM_NULL, CLAIM_DELEGATE_CUR, or CLAIM_DELEGATE_PREV,
because these claim methods include a component of a file name. because these claim methods include a component of a file name.
Upon success (which might entail creation of a new file), the current
filehandle is replaced by that of the created or existing object.
If the current filehandle is a named attribute directory, OPEN will If the current filehandle is a named attribute directory, OPEN will
then create or open a named attribute file. Note that exclusive then create or open a named attribute file. Note that exclusive
create of a named attribute is not supported. If the createmode is create of a named attribute is not supported. If the createmode is
EXCLUSIVE4 or EXCLUSIVE4_1 and the current filehandle is a named EXCLUSIVE4 or EXCLUSIVE4_1 and the current filehandle is a named
attribute directory, the server will return EINVAL. attribute directory, the server will return EINVAL.
UNCHECKED4 means that the file should be created if a file of that UNCHECKED4 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 does not exist and encountering an existing regular file of that
name is not an error. For this type of create, createattrs specifies name is not an error. For this type of create, createattrs specifies
the initial set of attributes for the file. The set of attributes the initial set of attributes for the file. The set of attributes
may include any writable attribute valid for regular files. When an may include any writable attribute valid for regular files. When an
UNCHECKED4 create encounters an existing file, the attributes UNCHECKED4 create encounters an existing file, the attributes
specified by createattrs are not used, except that when createattrs specified by createattrs are not used, except that when createattrs
specifies the size attribute with a size of zero, the existing file specifies the size attribute with a size of zero, the existing file
is truncated. is truncated.
If GUARDED4 is specified, the server checks for the presence of a If GUARDED4 is specified, the server checks for the presence of a
duplicate object by name before performing the create. If a duplicate object by name before performing the create. If a
duplicate exists, an error of NFS4ERR_EXIST is returned as the duplicate exists, NFS4ERR_EXIST is returned. If the object does not
status. If the object does not exist, the request is performed as exist, the request is performed as described for UNCHECKED4.
described for UNCHECKED4.
For the UNCHECKED4 and GUARDED4 cases, where the operation is For the UNCHECKED4 and GUARDED4 cases, where the operation is
successful, the server will return to the client an attribute mask successful, the server will return to the client an attribute mask
signifying which attributes were successfully set for the object. signifying which attributes were successfully set for the object.
EXCLUSIVE4_1 and EXCLUSIVE4 specify that the server is to follow EXCLUSIVE4_1 and EXCLUSIVE4 specify that the server is to follow
exclusive creation semantics, using the verifier to ensure exclusive exclusive creation semantics, using the verifier to ensure exclusive
creation of the target. The server should check for the presence of 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 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 creates the object and stores the verifier with the object. If the
skipping to change at page 428, line 44 skipping to change at page 429, line 18
In NFSv4.1, EXCLUSIVE4 has been deprecated in favor of EXCLUSIVE4_1. In NFSv4.1, EXCLUSIVE4 has been deprecated in favor of EXCLUSIVE4_1.
Unlike EXCLUSIVE4, attributes may be provided in the EXCLUSIVE4_1 Unlike EXCLUSIVE4, attributes may be provided in the EXCLUSIVE4_1
case, but because the server may use attributes of the target object case, but because the server may use attributes of the target object
to store the verifier, the set of allowable attributes may be fewer to store the verifier, the set of allowable attributes may be fewer
than the set of attributes SETATTR allows. The allowable attributes than the set of attributes SETATTR allows. The allowable attributes
for EXCLUSIVE4_1 are indicated in the suppattr_exclcreat for EXCLUSIVE4_1 are indicated in the suppattr_exclcreat
(Section 5.7.1.14) attribute. If the client attempts to set in (Section 5.7.1.14) attribute. If the client attempts to set in
cva_attrs an attribute that is not in suppattr_exclcreat, the server cva_attrs an attribute that is not in suppattr_exclcreat, the server
MUST return NFS4ERR_INVAL. The response field, attrset indicates MUST return NFS4ERR_INVAL. The response field, attrset indicates
both which attributes the server set from cva_attrs, and which both which attributes the server set from cva_attrs, and which
attributes the server used to store the verifier. The client can attributes the server used to store the verifier. As described in
logically AND cva_attrs.attrmask with attrset to determine which Section 18.16.4, the client can compare cva_attrs.attrmask with
attributes were used to store the verifier. attrset to determine which attributes were used to store the
verifier.
With the addition of persistent sessions and pNFS, under some With the addition of persistent sessions and pNFS, under some
conditions EXCLUSIVE4 MUST NOT be used by the client or supported the conditions EXCLUSIVE4 MUST NOT be used by the client or supported by
server. The following table summarizes the appropriate and mandated the server. The following table summarizes the appropriate and
exclusive create methods for implementations of NFSv4.1: mandated exclusive create methods for implementations of NFSv4.1:
Required methods for exclusive create Required methods for exclusive create
+--------------+--------+-----------------+-------------------------+ +--------------+--------+-----------------+-------------------------+
| Persistent | pNFS | Server REQUIRED | Client Allowed | | Persistent | pNFS | Server REQUIRED | Client Allowed |
| Reply Cache | server | | | | Reply Cache | server | | |
+--------------+--------+-----------------+-------------------------+ +--------------+--------+-----------------+-------------------------+
| no | no | EXCLUSIVE4_1 | EXCLUSIVE4_1 (SHOULD) | | no | no | EXCLUSIVE4_1 | EXCLUSIVE4_1 (SHOULD) |
| | | and EXCLUSIVE4 | or EXCLUSIVE4 (SHOULD | | | | and EXCLUSIVE4 | or EXCLUSIVE4 (SHOULD |
| | | | NOT) | | | | | NOT) |
| no | yes | EXCLUSIVE4_1 | EXCLUSIVE4_1 | | no | yes | EXCLUSIVE4_1 | EXCLUSIVE4_1 |
| yes | no | GUARDED4 | GUARDED4 | | yes | no | GUARDED4 | GUARDED4 |
| yes | yes | GUARDED4 | GUARDED4 | | yes | yes | GUARDED4 | GUARDED4 |
+--------------+--------+-----------------+-------------------------+ +--------------+--------+-----------------+-------------------------+
Table 18 Table 18
If CREATE_SESSION4_FLAG_PERSIST is set in the results of If CREATE_SESSION4_FLAG_PERSIST is set in the results of
CREATE_SESSION the reply cache is persistent. If the CREATE_SESSION the reply cache is persistent (see Section 18.36). If
EXCHGID4_FLAG_USE_PNFS_MDS flag is set in the results from the EXCHGID4_FLAG_USE_PNFS_MDS flag is set in the results from
EXCHANGE_ID, the server is a pNFS server. If the client attempts to EXCHANGE_ID, the server is a pNFS server (see Section 18.35). If the
use EXCLUSIVE4 on a persistent session, or a session derived from a client attempts to use EXCLUSIVE4 on a persistent session, or a
EXCHGID4_FLAG_USE_PNFS_MDS client ID, the server MUST return session derived from a EXCHGID4_FLAG_USE_PNFS_MDS client ID, the
NFS4ERR_INVAL. server MUST return NFS4ERR_INVAL.
With persistent sessions, exclusive create semantics are fully With persistent sessions, exclusive create semantics are fully
achievable via GUARDED4, and so EXCLUSIVE4 or EXCLUSIVE4_1 MUST NOT achievable via GUARDED4, and so EXCLUSIVE4 or EXCLUSIVE4_1 MUST NOT
be used. When pNFS is being used, the layout_hint attribute might be used. When pNFS is being used, the layout_hint attribute might
not be supported after the file is created. Only the EXCLUSIVE4_1 not be supported after the file is created. Only the EXCLUSIVE4_1
and GUARDED methods of exclusive file creation allow the atomic and GUARDED methods of exclusive file creation allow the atomic
setting of attributes. setting of attributes.
For the target directory, the server returns change_info4 information For the target directory, the server returns change_info4 information
in cinfo. With the atomic field of the change_info4 data type, the in cinfo. With the atomic field of the change_info4 data type, the
server will indicate if the before and after change attributes were server will indicate if the before and after change attributes were
obtained atomically with respect to the link creation. 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 The OPEN operation provides for Windows share reservation capability
with the use of the share_access and share_deny fields of the OPEN with the use of the share_access and share_deny fields of the OPEN
arguments. The client specifies at OPEN the required share_access arguments. The client specifies at OPEN the required share_access
and share_deny modes. For clients that do not directly support and share_deny modes. For clients that do not directly support
SHAREs (i.e. UNIX), the expected deny value is DENY_NONE. In the SHAREs (i.e. UNIX), the expected deny value is DENY_NONE. In the
case that there is a existing SHARE reservation that conflicts with case that there is a existing SHARE reservation that conflicts with
the OPEN request, the server returns the error NFS4ERR_SHARE_DENIED. the OPEN request, the server returns the error NFS4ERR_SHARE_DENIED.
For each OPEN, the client must provide a value for the owner field For additional discussion of SHARE semantics see Section 9.7.
for the OPEN argument. The client ID associated with the owner is
not derived from the client field of the owner parameter but is
instead the client ID associated with the session on which the
request is sent. If the client ID field of the owner parameter is
not zero, the server MUST return an NFS4ERR_INVAL error. For
additional discussion of SHARE semantics see Section 9.7.
The seqid value is not used in NFSv4.1, but it MAY be any value and For each OPEN, the client provides a value for the owner field of the
the server MUST ignore it. OPEN argument. The owner field is of data type open_owner4, and
contains a field called clientid and a field called owner. The
client can set the clientid field to any value and the server MUST
ignore it. Instead the server MUST derive the client ID from the
sessionid of the SEQUENCE operation of the COMPOUND request.
The seqid field of the request is not used in NFSv4.1, but it MAY be
any value and the server MUST ignore it.
In the case that the client is recovering state from a server 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 failure, the claim field of the OPEN argument is used to signify that
the request is meant to reclaim state previously held. the request is meant to reclaim state previously held.
The "claim" field of the OPEN argument is used to specify the file to 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 be opened and the state information which the client claims to
possess. There are seven claim types as follows: possess. There are seven claim types as follows:
+----------------------+--------------------------------------------+ +----------------------+--------------------------------------------+
skipping to change at page 432, line 45 skipping to change at page 433, line 21
As with the CREATE operation, the server MUST derive the owner, owner 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 ACE, group, or group ACE if any of the four attributes are required
and supported by the server's file system. For an OPEN with the and supported by the server's file system. For an OPEN with the
EXCLUSIVE4 createmode, the server has no choice, since such OPEN EXCLUSIVE4 createmode, the server has no choice, since such OPEN
calls do not include the createattrs field. Conversely, if calls do not include the createattrs field. Conversely, if
createattrs (UNCHECKED4 or GUARDED4) or cva_attrs (EXCLUSIVE4_1) is createattrs (UNCHECKED4 or GUARDED4) or cva_attrs (EXCLUSIVE4_1) is
specified, and includes an owner, or owner_group, or ACE that the specified, and includes an owner, or owner_group, or ACE that the
principal in the RPC call's credentials does not have authorization principal in the RPC call's credentials does not have authorization
to create files for, then the server may return NFS4ERR_PERM. 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. In the case of an OPEN which specifies a size of zero (e.g.
truncation) and the file has named attributes, the named attributes truncation) and the file has named attributes, the named attributes
are left as is. They are not removed. are left as is and are not removed.
NFSv4.1 gives more precise control to clients over acquisition of NFSv4.1 gives more precise control to clients over acquisition of
delegations via the following new flags for the share_access field of delegations via the following new flags for the share_access field of
OPEN4args: OPEN4args:
OPEN4_SHARE_ACCESS_WANT_READ_DELEG OPEN4_SHARE_ACCESS_WANT_READ_DELEG
OPEN4_SHARE_ACCESS_WANT_WRITE_DELEG OPEN4_SHARE_ACCESS_WANT_WRITE_DELEG
OPEN4_SHARE_ACCESS_WANT_ANY_DELEG OPEN4_SHARE_ACCESS_WANT_ANY_DELEG
skipping to change at page 433, line 38 skipping to change at page 434, line 16
OPEN4_SHARE_ACCESS_WANT_NO_DELEG OPEN4_SHARE_ACCESS_WANT_NO_DELEG
OPEN4_SHARE_ACCESS_WANT_CANCEL OPEN4_SHARE_ACCESS_WANT_CANCEL
Otherwise the client is indicating no desire for a delegation and the Otherwise the client is indicating no desire for a delegation and the
server MAY or MAY not return a delegation in the OPEN response. server MAY or MAY not return a delegation in the OPEN response.
If the server supports the new _WANT_ flags and the client sends one If the server supports the new _WANT_ flags and the client sends one
or more of the new flags, then in the event the server does not or more of the new flags, then in the event the server does not
return a delegation, it MUST return a delegation type of return a delegation, it MUST return a delegation type of
OPEN_DELEGATE_NONE_EXT. od_whynone indicates why no delegation was OPEN_DELEGATE_NONE_EXT. The field od_whynone in the reply indicates
returned and will be one of: why no delegation was returned and will be one of:
WND4_NOT_WANTED The client specified WND4_NOT_WANTED The client specified
OPEN4_SHARE_ACCESS_WANT_NO_DELEG. OPEN4_SHARE_ACCESS_WANT_NO_DELEG.
WND4_CONTENTION There is a conflicting delegation or open on the WND4_CONTENTION There is a conflicting delegation or open on the
file. file.
WND4_RESOURCE Resource limitations prevent the server from granting WND4_RESOURCE Resource limitations prevent the server from granting
a delegation. a delegation.
skipping to change at page 436, line 9 skipping to change at page 436, line 34
create by setting the how parameter to EXCLUSIVE4 or EXCLUSIVE4_1. create by setting the how parameter to EXCLUSIVE4 or EXCLUSIVE4_1.
In these cases, the client provides a verifier that can reasonably be In these cases, the client provides a verifier that can reasonably be
expected to be unique. A combination of a client identifier, perhaps expected to be unique. A combination of a client identifier, perhaps
the client network address, and a unique number generated by the the client network address, and a unique number generated by the
client, perhaps the RPC transaction identifier, may be appropriate. client, perhaps the RPC transaction identifier, may be appropriate.
If the object does not exist, the server creates the object and If the object does not exist, the server creates the object and
stores the verifier in stable storage. For file systems that do not stores the verifier in stable storage. For file systems that do not
provide a mechanism for the storage of arbitrary file attributes, the provide a mechanism for the storage of arbitrary file attributes, the
server may use one or more elements of the object metadata to store server may use one or more elements of the object metadata to store
the verifier. The verifier must be stored in stable storage to the verifier. The verifier MUST be stored in stable storage to
prevent erroneous failure on retransmission of the request. It is prevent erroneous failure on retransmission of the request. It is
assumed that an exclusive create is being performed because exclusive assumed that an exclusive create is being performed because exclusive
semantics are critical to the application. Because of the expected semantics are critical to the application. Because of the expected
usage, exclusive CREATE does not rely solely on the server's reply usage, exclusive CREATE does not rely solely on the server's reply
cache for storage of the verifier. A nonpersistent reply cache does cache for storage of the verifier. A nonpersistent reply cache does
not survive a crash and the session and reply cache may be deleted not survive a crash and the session and reply cache may be deleted
after a network partition that exceeds the lease time, thus opening after a network partition that exceeds the lease time, thus opening
failure windows. failure windows.
An NFSv4.1 server SHOULD NOT store the verifier in any of the file's An NFSv4.1 server SHOULD NOT store the verifier in any of the file's
skipping to change at page 437, line 8 skipping to change at page 437, line 34
server reconstructs the object's verifier and compares it with the server reconstructs the object's verifier and compares it with the
verifier in the request. If they match, the server treats 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 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 an earlier, successful request for which the reply was lost and that
the server duplicate request cache mechanism did not detect. If the the server duplicate request cache mechanism did not detect. If the
verifiers do not match, the request is rejected with the status, verifiers do not match, the request is rejected with the status,
NFS4ERR_EXIST. NFS4ERR_EXIST.
After the client has performed a successful exclusive create, the After the client has performed a successful exclusive create, the
attrset response indicates which attributes were used to store the attrset response indicates which attributes were used to store the
verifier. If EXCLUSIVE4 was used, any attribute set in attrset was verifier. If EXCLUSIVE4 was used, the attributes set in attrset were
used for the verifier. If EXCLUSIVE4_1 was used, the client used for the verifier. If EXCLUSIVE4_1 was used, the client
determines the attributes used for the verifier by comparing attrset determines the attributes used for the verifier by comparing attrset
with cva_attrs.attrmask; any bits set in former but not the latter with cva_attrs.attrmask; any bits set in the former but not the
identify the attributes used store the verifier. The client MUST latter identify the attributes used store the verifier. The client
immediately send a SETATTR on attributes used to store the verifier. MUST immediately send a SETATTR to set attributes used to store the
Until it does so, the attributes used to store the verifier cannot be verifier. Until it does so, the attributes used to store the
relied upon. The subsequent SETATTR must not occur in the same verifier cannot be relied upon. The subsequent SETATTR MUST NOT
COMPOUND request as the OPEN. occur in the same COMPOUND request as the OPEN.
Unless a persistent session is used, use of the GUARDED4 attribute Unless a persistent session is used, use of the GUARDED4 attribute
does not provide exactly-once semantics. In particular, if a reply does not provide exactly-once semantics. In particular, if a reply
is lost and the server does not detect the retransmission of the is lost and the server does not detect the retransmission of the
request, the operation can fail with NFS4ERR_EXIST, even though the request, the operation can fail with NFS4ERR_EXIST, even though the
create was performed successfully. The client would use this create was performed successfully. The client would use this
behavior in the case that the application has not requested an behavior in the case that the application has not requested an
exclusive create but has asked to have the file truncated when the exclusive create but has asked to have the file truncated when the
file is opened. In the case of the client timing out and file is opened. In the case of the client timing out and
retransmitting the create request, the client can use GUARDED4 to retransmitting the create request, the client can use GUARDED4 to
prevent against a sequence like: create, write, create prevent against a sequence like: create, write, create
(retransmitted) from occurring. (retransmitted) from occurring.
For SHARE reservations, the client must specify a value for For SHARE reservations, the client MUST specify a value for
share_access that is one of READ, WRITE, or BOTH. For share_deny, share_access that is one of READ, WRITE, or BOTH. For share_deny,
the client must specify one of NONE, READ, WRITE, or BOTH. If the the client MUST specify one of NONE, READ, WRITE, or BOTH. If the
client fails to do this, the server must return NFS4ERR_INVAL. client fails to do this, the server MUST return NFS4ERR_INVAL.
Based on the share_access value (READ, WRITE, or BOTH) the client Based on the share_access value (READ, WRITE, or BOTH) the client
should check that the requester has the proper access rights to should check that the requester has the proper access rights to
perform the specified operation. This would generally be the results perform the specified operation. This would generally be the results
of applying the ACL access rules to the file for the current of applying the ACL access rules to the file for the current
requester. However, just as with the ACCESS operation, the client requester. However, just as with the ACCESS operation, the client
should not attempt to second-guess the server's decisions, as access should not attempt to second-guess the server's decisions, as access
rights may change and may be subject to server administrative rights may change and may be subject to server administrative
controls outside the ACL framework. If the requester is not controls outside the ACL framework. If the requester is not
authorized to READ or WRITE (depending on the share_access value), authorized to READ or WRITE (depending on the share_access value),
the server must return NFS4ERR_ACCESS. Note that since the NFSv4.1 the server MUST return NFS4ERR_ACCESS.
protocol does not impose any requirement that READs and WRITEs sent
for an open file have the same credentials as the OPEN itself, the Note that if the client ID was not created with
server still must do appropriate access checking on the READs and EXCHGID4_FLAG_BIND_PRINC_STATEID set in the reply to EXCHANGE_ID,
WRITEs themselves. then the server MUST NOT impose any requirement that READs and WRITEs
sent for an open file have the same credentials as the OPEN itself,
and the server is REQUIRED to perform access checking on the READs
and WRITEs themselves. Otherwise, if the reply to EXCHANGE_ID did
have EXCHGID4_FLAG_BIND_PRINC_STATEID set, then with one exception,
the credentials used in the OPEN request MUST match those used in the
READs and WRITEs, and the stateids in the READs and WRITEs MUST
match, or be derived from the stateid from the reply to OPEN. The
exception is if SP4_SSV or SP4_MACH_CRED state protection is used,
and the spo_must_allow result of EXCHANGE_ID includes the READ and/or
WRITE operations. In that case, the machine or SSV credential will
be allowed to issue READ and/or WRITE. See Section 18.35.
If the component provided to OPEN is a symbolic link, the error If the component provided to OPEN is a symbolic link, the error
NFS4ERR_SYMLINK will be returned to the client, while if it is a NFS4ERR_SYMLINK will be returned to the client, while if it is a
directory the error NFS4ERR_ISDIR. If the component is neither of directory the error NFS4ERR_ISDIR. If the component is neither of
those but not an ordinary file, the error NFS4ERR_WRONG_TYPE is those but not an ordinary file, the error NFS4ERR_WRONG_TYPE is
returned. If the current filehandle is not a directory, the error returned. If the current filehandle is not a directory, the error
NFS4ERR_NOTDIR will be returned. NFS4ERR_NOTDIR will be returned.
The use of the OPEN4_RESULT_PRESERVE_UNLINKED result flag allows a The use of the OPEN4_RESULT_PRESERVE_UNLINKED result flag allows a
client avoid the common implementation practice of renaming an open client avoid the common implementation practice of renaming an open
file to ".nfs<unique value>" after it removes the file. After the file to ".nfs<unique value>" after it removes the file. After the
server returns OPEN4_RESULT_PRESERVE_UNLINKED, if a client sends a server returns OPEN4_RESULT_PRESERVE_UNLINKED, if a client sends a
REMOVE operation that would reduce the file's link count to zero, the REMOVE operation that would reduce the file's link count to zero, the
server SHOULD report a value of zero for the numlinks attribute on server SHOULD report a value of zero for the numlinks attribute on
the file. the file.
If another client has a delegation of the file being opened that If another client has a delegation of the file being opened that
conflicts with open being done (sometimes depending of the conflicts with open being done (sometimes depending of the
share_access or share_deny value specified), the delegation(s) must share_access or share_deny value specified), the delegation(s) MUST
be recalled, and the operation cannot proceed until each such be recalled, and the operation cannot proceed until each such
delegation is returned or revoked. Except where this happens very delegation is returned or revoked. Except where this happens very
quickly, one or more NFS4ERR_DELAY errors will be returned to quickly, one or more NFS4ERR_DELAY errors will be returned to
requests made while delegation remains outstanding. In the case of a requests made while delegation remains outstanding. In the case of a
write delegation, any open by a different client will conflict, while write delegation, any open by a different client will conflict, while
for a read delegation only opens with one of the following for a read delegation only opens with one of the following
characteristics will be considered conflicting: characteristics will be considered conflicting:
o The value of share_access includes the bit o The value of share_access includes the bit
OPEN4_SHARE_ACCESS_WRITE. OPEN4_SHARE_ACCESS_WRITE.
skipping to change at page 438, line 41 skipping to change at page 439, line 30
o The value of share_deny specifies READ or BOTH. o The value of share_deny specifies READ or BOTH.
o OPEN4_CREATE is specified together with UNCHECKED4, the size o OPEN4_CREATE is specified together with UNCHECKED4, the size
attribute is specified as zero (for truncation) and an existing attribute is specified as zero (for truncation) and an existing
file is truncated. file is truncated.
If OPEN4_CREATE is specified and the file does not exist and the If OPEN4_CREATE is specified and the file does not exist and the
current filehandle designates a directory for which another client current filehandle designates a directory for which another client
holds a directory delegation, then, unless the delegation is such holds a directory delegation, then, unless the delegation is such
that the situation can be resolved by sending a notification, the that the situation can be resolved by sending a notification, the
delegation must be recalled, and the operation cannot proceed until delegation MUST be recalled, and the operation cannot proceed until
the delegation is returned or revoked. Except where this happens the delegation is returned or revoked. Except where this happens
very quickly, one or more NFS4ERR_DELAY errors will be returned to very quickly, one or more NFS4ERR_DELAY errors will be returned to
requests made while delegation remains outstanding. requests made while delegation remains outstanding.
If OPEN4_CREATE is specified and the file does not exist and the If OPEN4_CREATE is specified and the file does not exist and the
current filehandle designates a directory for which one or more current filehandle designates a directory for which one or more
directory delegations exist, then, when those delegations request directory delegations exist, then, when those delegations request
such notifications, NOTIFY4_ADD_ENTRY will be generated as a result such notifications, NOTIFY4_ADD_ENTRY will be generated as a result
of this operation. of this operation.
skipping to change at page 439, line 21 skipping to change at page 440, line 10
to determine which file to close. Therefore the client MUST follow to determine which file to close. Therefore the client MUST follow
every OPEN operation with a GETFH operation in the same COMPOUND every OPEN operation with a GETFH operation in the same COMPOUND
procedure. This will supply the client with the filehandle such that procedure. This will supply the client with the filehandle such that
CLOSE can be used appropriately. CLOSE can be used appropriately.
Simply waiting for the lease on the file to expire is insufficient Simply waiting for the lease on the file to expire is insufficient
because the server may maintain the state indefinitely as long as because the server may maintain the state indefinitely as long as
another client does not attempt to make a conflicting access to the another client does not attempt to make a conflicting access to the
same file. same file.
See also Section 2.10.5.4.
18.17. Operation 19: OPENATTR - Open Named Attribute Directory 18.17. Operation 19: OPENATTR - Open Named Attribute Directory
18.17.1. ARGUMENTS 18.17.1. ARGUMENTS
struct OPENATTR4args { struct OPENATTR4args {
/* CURRENT_FH: object */ /* CURRENT_FH: object */
bool createdir; bool createdir;
}; };
18.17.2. RESULTS 18.17.2. RESULTS
 End of changes. 66 change blocks. 
177 lines changed or deleted 213 lines changed or added

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