RFC1094] and the NFS version 3 protocol [RFC1813], there exists an ancillary protocol to obtain this first filehandle. The MOUNT protocol, RPC program number 100005, provides the mechanism of translating a string based file system path name to a filehandle which can then be used by the NFS protocols. The MOUNT protocol has deficiencies in the area of security and use via firewalls. This is one reason that the use of the public filehandle was introduced in [RFC2054] and [RFC2055]. With the use of the public filehandle in combination with the LOOKUP procedure in the NFS version 2 and 3 protocols, it has been demonstrated that the MOUNT protocol is unnecessary for viable interaction between NFS client and server. Therefore, the NFS version 4 protocol will not use an ancillary protocol for translation from string based path names to a filehandle. Two special filehandles will be used as starting points for the NFS client.
Further discussion of filehandle and attribute comparison in the context of data caching is presented in the section "Data Caching and File Identity". As an example, in the case that two different path names when traversed at the server terminate at the same file system object, the server SHOULD return the same filehandle for each path. This can occur if a hard link is used to create two file names which refer to the same underlying file object and associated data. For example, if paths /a/b/c and /a/d/c refer to the same file, the server SHOULD return the same filehandle for both path names traversals.
The mandatory attribute "fh_expire_type" is used by the client to determine what type of filehandle the server is providing for a particular file system. This attribute is a bitmask with the following values: FH4_PERSISTENT The value of FH4_PERSISTENT is used to indicate a persistent filehandle, which is valid until the object is removed from the file system. The server will not return NFS4ERR_FHEXPIRED for this filehandle. FH4_PERSISTENT is defined as a value in which none of the bits specified below are set. FH4_NOEXPIRE_WITH_OPEN The filehandle will not expire while client has the file open. If this bit is set, then the values FH4_VOLATILE_ANY or FH4_VOL_RENAME do not impact expiration while the file is open. Once the file is closed or if the FH4_NOEXPIRE_WITH_OPEN bit is false, the rest of the volatile related bits apply. FH4_VOLATILE_ANY The filehandle may expire at any time and will expire during system migration and rename. FH4_VOL_MIGRATION The filehandle will expire during file system migration. May only be set if FH4_VOLATILE_ANY is not set. FH4_VOL_RENAME The filehandle may expire due to a rename. This includes a rename by the requesting client or a rename by another client. May only be set if FH4_VOLATILE_ANY is not set. Servers which provide volatile filehandles should deny a RENAME or REMOVE that would affect an OPEN file or any of the components leading to the OPEN file. In addition, the server should deny all RENAME or REMOVE requests during the grace or lease period upon server restart. The reader may be wondering why there are three FH4_VOL* bits and why FH4_VOLATILE_ANY is exclusive of FH4_VOL_MIGRATION and FH4_VOL_RENAME. If the a filehandle is normally persistent but cannot persist across a file set migration, then the presence of the FH4_VOL_MIGRATION or FH4_VOL_RENAME tells the client that it can treat the file handle as persistent for purposes of maintaining a file name to file handle cache, except for the specific event described by the bit. However, FH4_VOLATILE_ANY tells the client that it should not maintain such a cache for unopened files. A server MUST not present FH4_VOLATILE_ANY with FH4_VOL_MIGRATION or
FH4_VOL_RENAME as this will lead to confusion. FH4_VOLATILE_ANY implies that the file handle will expire upon migration or rename, in addition to other events.
If the expired filehandle refers to an object that has been removed from the file system, obviously the client will not be able to recover from the expired filehandle. It is also possible that the expired filehandle refers to a file that has been renamed. If the file was renamed by another client, again it is possible that the original client will not be able to recover. However, in the case that the client itself is renaming the file and the file is open, it is possible that the client may be able to recover. The client can determine the new path name based on the processing of the rename request. The client can then regenerate the new filehandle based on the new path name. The client could also use the compound operation mechanism to construct a set of operations like: RENAME A B LOOKUP B GETFH
or READDIR and contains files whose names represent the named attributes and whose data bytes are the value of the attribute. For example: LOOKUP "foo" ; look up file GETATTR attrbits OPENATTR ; access foo's named attributes LOOKUP "x11icon" ; look up specific attribute READ 0,4096 ; read stream of bytes Named attributes are intended for data needed by applications rather than by an NFS client implementation. NFS implementors are strongly encouraged to define their new attributes as recommended attributes by bringing them to the IETF standards-track process. The set of attributes which are classified as mandatory is deliberately small since servers must do whatever it takes to support them. The recommended attributes may be unsupported; though a server should support as many as it can. Attributes are deemed mandatory if the data is both needed by a large number of clients and is not otherwise reasonably computable by the client when support is not provided on the server.
they don't have to "tell lies" to the client. For example, a file modification time should be either an accurate time or should not be supported by the server. This will not always be comfortable to clients but it seems that the client has a better ability to fabricate or construct an attribute or do without the attribute.
fh_expire_type 2 uint32 READ Server uses this to specify filehandle expiration behavior to the client. See the section "Filehandles" for additional description. change 3 uint64 READ A value created by the server that the client can use to determine if file data, directory contents or attributes of the object have been modified. The server may return the object's time_modify attribute for this attribute's value but only if the file system object can not be updated more frequently than the resolution of time_modify. size 4 uint64 R/W The size of the object in bytes. link_support 5 boolean READ Does the object's file system supports hard links? symlink_support 6 boolean READ Does the object's file system supports symbolic links? named_attr 7 boolean READ Does this object have named attributes? fsid 8 fsid4 READ Unique file system identifier for the file system holding this object. fsid contains major and minor components each of which are uint64.
unique_handles 9 boolean READ Are two distinct filehandles guaranteed to refer to two different file system objects? lease_time 10 nfs_lease4 READ Duration of leases at server in seconds. rdattr_error 11 enum READ Error returned from getattr during readdir.
chown_restricted 18 boolean READ If TRUE, the server will reject any request to change either the owner or the group associated with a file if the caller is not a privileged user (for example, "root" in Unix operating environments or in NT the "Take Ownership" privilege) filehandle 19 nfs4_fh READ The filehandle of this object (primarily for readdir requests). fileid 20 uint64 READ A number uniquely identifying the file within the file system. files_avail 21 uint64 READ File slots available to this user on the file system containing this object - this should be the smallest relevant limit. files_free 22 uint64 READ Free file slots on the file system containing this object - this should be the smallest relevant limit. files_total 23 uint64 READ Total file slots on the file system containing this object.
fs_locations 24 fs_locations READ Locations where this file system may be found. If the server returns NFS4ERR_MOVED as an error, this attribute must be supported. hidden 25 boolean R/W Is file considered hidden with respect to the WIN32 API? homogeneous 26 boolean READ Whether or not this object's file system is homogeneous, i.e. are per file system attributes the same for all file system's objects. maxfilesize 27 uint64 READ Maximum supported file size for the file system of this object. maxlink 28 uint32 READ Maximum number of links for this object. maxname 29 uint32 READ Maximum filename size supported for this object. maxread 30 uint64 READ Maximum read size supported for this object. maxwrite 31 uint64 READ Maximum write size supported for this object. This attribute SHOULD be supported if the file is writable. Lack of this attribute can lead to the client either wasting
bandwidth or not receiving the best performance. mimetype 32 utf8<> R/W MIME body type/subtype of this object. mode 33 mode4 R/W Unix-style permission bits for this object (deprecated in favor of ACLs) no_trunc 34 boolean READ If a name longer than name_max is used, will an error be returned or will the name be truncated? numlinks 35 uint32 READ Number of hard links to this object. owner 36 utf8<> R/W The string name of the owner of this object. owner_group 37 utf8<> R/W The string name of the group ownership of this object. quota_avail_hard 38 uint64 READ For definition see "Quota Attributes" section below. quota_avail_soft 39 uint64 READ For definition see "Quota Attributes" section below. quota_used 40 uint64 READ For definition see "Quota Attributes" section below. rawdev 41 specdata4 READ Raw device identifier. Unix device major/minor node information.
space_avail 42 uint64 READ Disk space in bytes available to this user on the file system containing this object - this should be the smallest relevant limit. space_free 43 uint64 READ Free disk space in bytes on the file system containing this object - this should be the smallest relevant limit. space_total 44 uint64 READ Total disk space in bytes on the file system containing this object. space_used 45 uint64 READ Number of file system bytes allocated to this object. system 46 boolean R/W Is this file a system file with respect to the WIN32 API? time_access 47 nfstime4 READ The time of last access to the object. time_access_set 48 settime4 WRITE Set the time of last access to the object. SETATTR use only. time_backup 49 nfstime4 R/W The time of last backup of the object. time_create 50 nfstime4 R/W The time of creation of the object. This attribute does not have any relation to the traditional Unix file attribute "ctime" or "change time".
time_delta 51 nfstime4 READ Smallest useful server time granularity. time_metadata 52 nfstime4 R/W The time of last meta-data modification of the object. time_modify 53 nfstime4 READ The time of last modification to the object. time_modify_set 54 settime4 WRITE Set the time of last modification to the object. SETATTR use only. RFC2624] provides additional rationale. It is expected that the client and server will have their own local representation of owner and owner_group that is used for local storage or presentation to the end user. Therefore, it is expected that when these attributes are transferred between the client and server that the local representation is translated to a syntax of the form "user@dns_domain". This will allow for a client and server that do not use the same local representation the ability to translate to a common syntax that can be interpreted by both. The translation is not specified as part of the protocol. This allows various solutions to be employed. For example, a local translation table may be consulted that maps between a numeric id to the user@dns_domain syntax. A name service may also be used to accomplish the translation. The "dns_domain" portion of the owner string is meant to be a DNS domain name. For example, firstname.lastname@example.org. In the case where there is no translation available to the client or server, the attribute value must be constructed without the "@". Therefore, the absence of the @ from the owner or owner_group attribute signifies that no translation was available and the receiver of the attribute should not place any special meaning with
the attribute value. Even though the attribute value can not be translated, it may still be useful. In the case of a client, the attribute string may be used for local display of ownership. RFC1345] which may or may not included the word "CAPITAL" or "SMALL". The presence of SMALL or CAPITAL allows an NFS server to implement unambiguous and efficient table driven mappings for case insensitive comparisons, and non-case-preserving storage. For general character handling and internationalization issues, see the section "Internationalization".
The server is at liberty to choose any of those sets but should do so in a repeatable way. The rule may be configured per- filesystem or may be "choose the set with the smallest quota".
is no longer considered in the processing of later ACEs. If an ACCESS_DENIED_ACE is encountered where the requester's mode still has unALLOWED bits in common with the "access_mask" of the ACE, the request is denied. The bitmask constants used to represent the above definitions within the aclsupport attribute are as follows: const ACL4_SUPPORT_ALLOW_ACL = 0x00000001; const ACL4_SUPPORT_DENY_ACL = 0x00000002; const ACL4_SUPPORT_AUDIT_ACL = 0x00000004; const ACL4_SUPPORT_ALARM_ACL = 0x00000008;
Can be placed on a directory. Normally when a new directory is created and an ACE exists on the parent directory which is marked ACL4_DIRECTORY_INHERIT_ACE, two ACEs are placed on the new directory. One for the directory itself and one which is an inheritable ACE for newly created directories. This flag tells the server to not place an ACE on the newly created directory which is inheritable by subdirectories of the created directory. ACE4_SUCCESSFUL_ACCESS_ACE_FLAG ACL4_FAILED_ACCESS_ACE_FLAG Both indicate for AUDIT and ALARM which state to log the event. On every ACCESS or OPEN call which occurs on a file or directory which has an ACL that is of type ACE4_SYSTEM_AUDIT_ACE_TYPE or ACE4_SYSTEM_ALARM_ACE_TYPE, the attempted access is compared to the ace4mask of these ACLs. If the access is a subset of ace4mask and the identifier match, an AUDIT trail or an ALARM is generated. By default this happens regardless of the success or failure of the ACCESS or OPEN call. The flag ACE4_SUCCESSFUL_ACCESS_ACE_FLAG only produces the AUDIT or ALARM if the ACCESS or OPEN call is successful. The ACE4_FAILED_ACCESS_ACE_FLAG causes the ALARM or AUDIT if the ACCESS or OPEN call fails. ACE4_IDENTIFIER_GROUP Indicates that the "who" refers to a GROUP as defined under Unix. The bitmask constants used for the flag field are as follows: const ACE4_FILE_INHERIT_ACE = 0x00000001; const ACE4_DIRECTORY_INHERIT_ACE = 0x00000002; const ACE4_NO_PROPAGATE_INHERIT_ACE = 0x00000004; const ACE4_INHERIT_ONLY_ACE = 0x00000008; const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG = 0x00000010; const ACE4_FAILED_ACCESS_ACE_FLAG = 0x00000020; const ACE4_IDENTIFIER_GROUP = 0x00000040;
const ACE4_DELETE = 0x00010000; const ACE4_READ_ACL = 0x00020000; const ACE4_WRITE_ACL = 0x00040000; const ACE4_WRITE_OWNER = 0x00080000; const ACE4_SYNCHRONIZE = 0x00100000;
file writes which are represented by WRITE and COMMIT verifiers. The server should strive to minimize the impact on its clients during and after the migration process.
fs_locations attribute provided by servA would have a fs_root value of "/a/b/c" and two entries in fs_location. One entry in fs_location will be for itself (servA) and the other will be for servB with a path of "/x/y/z". With this information, the client is able to substitute "/x/y/z" for the "/a/b/c" at the beginning of its access path and construct "/x/y/z/d" to use for the new server.
The pseudo file system for this server may be constructed to look like: / (place holder/not exported) /a/b (file system 1) /a/b/c/d (file system 2) It is the server's responsibility to present the pseudo file system that is complete to the client. If the client sends a lookup request for the path "/a/b/c/d", the server's response is the filehandle of the file system "/a/b/c/d". In previous versions of the NFS protocol, the server would respond with the directory "/a/b/c/d" within the file system "/a/b". The NFS client will be able to determine if it crosses a server mount point by a change in the value of the "fsid" attribute.