rfc1094.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,515 行 · 第 1/4 页
TXT
1,515 行
empty.
NFSERR_DQUOT
Disk quota exceeded. The client's disk quota on the server has
been exceeded.
NFSERR_STALE
The "fhandle" given in the arguments was invalid. That is, the
file referred to by that file handle no longer exists, or access
to it has been revoked.
NFSERR_WFLUSH
The server's write cache used in the "WRITECACHE" call got flushed
to disk.
Sun Microsystems, Inc. [Page 14]
RFC 1094 NFS: Network File System March 1989
2.3.2. ftype
enum ftype {
NFNON = 0,
NFREG = 1,
NFDIR = 2,
NFBLK = 3,
NFCHR = 4,
NFLNK = 5
};
The enumeration "ftype" gives the type of a file. The type NFNON
indicates a non-file, NFREG is a regular file, NFDIR is a
directory, NFBLK is a block-special device, NFCHR is a character-
special device, and NFLNK is a symbolic link.
2.3.3. fhandle
typedef opaque fhandle[FHSIZE];
The "fhandle" is the file handle passed between the server and the
client. All file operations are done using file handles to refer
to a file or directory. The file handle can contain whatever
information the server needs to distinguish an individual file.
2.3.4. timeval
struct timeval {
unsigned int seconds;
unsigned int useconds;
};
The "timeval" structure is the number of seconds and microseconds
since midnight January 1, 1970, Greenwich Mean Time. It is used
to pass time and date information.
2.3.5. fattr
struct fattr {
ftype type;
unsigned int mode;
unsigned int nlink;
unsigned int uid;
unsigned int gid;
unsigned int size;
unsigned int blocksize;
unsigned int rdev;
unsigned int blocks;
Sun Microsystems, Inc. [Page 15]
RFC 1094 NFS: Network File System March 1989
unsigned int fsid;
unsigned int fileid;
timeval atime;
timeval mtime;
timeval ctime;
};
The "fattr" structure contains the attributes of a file; "type" is
the type of the file; "nlink" is the number of hard links to the
file (the number of different names for the same file); "uid" is
the user identification number of the owner of the file; "gid" is
the group identification number of the group of the file; "size"
is the size in bytes of the file; "blocksize" is the size in bytes
of a block of the file; "rdev" is the device number of the file if
it is type NFCHR or NFBLK; "blocks" is the number of blocks the
file takes up on disk; "fsid" is the file system identifier for
the filesystem containing the file; "fileid" is a number that
uniquely identifies the file within its filesystem; "atime" is the
time when the file was last accessed for either read or write;
"mtime" is the time when the file data was last modified
(written); and "ctime" is the time when the status of the file was
last changed. Writing to the file also changes "ctime" if the
size of the file changes.
"Mode" is the access mode encoded as a set of bits. Notice that
the file type is specified both in the mode bits and in the file
type. This is really a bug in the protocol and will be fixed in
future versions. The descriptions given below specify the bit
positions using octal numbers.
0040000 This is a directory; "type" field should be NFDIR.
0020000 This is a character special file; "type" field should
be NFCHR.
0060000 This is a block special file; "type" field should be
NFBLK.
0100000 This is a regular file; "type" field should be NFREG.
0120000 This is a symbolic link file; "type" field should be
NFLNK.
0140000 This is a named socket; "type" field should be NFNON.
0004000 Set user id on execution.
0002000 Set group id on execution.
0001000 Save swapped text even after use.
0000400 Read permission for owner.
0000200 Write permission for owner.
0000100 Execute and search permission for owner.
0000040 Read permission for group.
0000020 Write permission for group.
0000010 Execute and search permission for group.
Sun Microsystems, Inc. [Page 16]
RFC 1094 NFS: Network File System March 1989
0000004 Read permission for others.
0000002 Write permission for others.
0000001 Execute and search permission for others.
Notes: The bits are the same as the mode bits returned by the
stat(2) system call in UNIX. The file type is specified both in
the mode bits and in the file type. This is fixed in future
versions.
The "rdev" field in the attributes structure is an operating
system specific device specifier. It will be removed and
generalized in the next revision of the protocol.
2.3.6. sattr
struct sattr {
unsigned int mode;
unsigned int uid;
unsigned int gid;
unsigned int size;
timeval atime;
timeval mtime;
};
The "sattr" structure contains the file attributes which can be
set from the client. The fields are the same as for "fattr"
above. A "size" of zero means the file should be truncated. A
value of -1 indicates a field that should be ignored.
2.3.7. filename
typedef string filename<MAXNAMLEN>;
The type "filename" is used for passing file names or pathname
components.
2.3.8. path
typedef string path<MAXPATHLEN>;
The type "path" is a pathname. The server considers it as a
string with no internal structure, but to the client it is the
name of a node in a filesystem tree.
2.3.9. attrstat
union attrstat switch (stat status) {
case NFS_OK:
Sun Microsystems, Inc. [Page 17]
RFC 1094 NFS: Network File System March 1989
fattr attributes;
default:
void;
};
The "attrstat" structure is a common procedure result. It
contains a "status" and, if the call succeeded, it also contains
the attributes of the file on which the operation was done.
2.3.10. diropargs
struct diropargs {
fhandle dir;
filename name;
};
The "diropargs" structure is used in directory operations. The
"fhandle" "dir" is the directory in which to find the file "name".
A directory operation is one in which the directory is affected.
2.3.11. diropres
union diropres switch (stat status) {
case NFS_OK:
struct {
fhandle file;
fattr attributes;
} diropok;
default:
void;
};
The results of a directory operation are returned in a "diropres"
structure. If the call succeeded, a new file handle "file" and
the "attributes" associated with that file are returned along with
the "status".
3. NFS IMPLEMENTATION ISSUES
The NFS protocol was designed to allow different operating systems to
share files. However, since it was designed in a UNIX environment,
many operations have semantics similar to the operations of the UNIX
file system. This section discusses some of the implementation-
specific details and semantic issues.
3.1. Server/Client Relationship
The NFS protocol is designed to allow servers to be as simple and
Sun Microsystems, Inc. [Page 18]
RFC 1094 NFS: Network File System March 1989
general as possible. Sometimes the simplicity of the server can be a
problem, if the client wants to implement complicated filesystem
semantics.
For example, some operating systems allow removal of open files. A
process can open a file and, while it is open, remove it from the
directory. The file can be read and written as long as the process
keeps it open, even though the file has no name in the filesystem.
It is impossible for a stateless server to implement these semantics.
The client can do some tricks such as renaming the file on remove,
and only removing it on close. We believe that the server provides
enough functionality to implement most file system semantics on the
client.
Every NFS client can also potentially be a server, and remote and
local mounted filesystems can be freely intermixed. This leads to
some interesting problems when a client travels down the directory
tree of a remote filesystem and reaches the mount point on the server
for another remote filesystem. Allowing the server to follow the
second remote mount would require loop detection, server lookup, and
user revalidation. Instead, we decided not to let clients cross a
server's mount point. When a client does a LOOKUP on a directory on
which the server has mounted a filesystem, the client sees the
underlying directory instead of the mounted directory.
For example, if a server has a file system called "/usr" and mounts
another file system on "/usr/src", if a client mounts "/usr", it
does NOT see the mounted version of "/usr/src". A client could do
remote mounts that match the server's mount points to maintain the
server's view. In this example, the client would also have to mount
"/usr/src" in addition to "/usr", even if they are from the same
server.
3.2. Pathname Interpretation
There are a few complications to the rule that pathnames are always
parsed on the client. For example, symbolic links could have
different interpretations on different clients. Another common
problem for non-UNIX implementations is the special interpretation of
the pathname ".." to mean the parent of a given directory. The next
revision of the protocol uses an explicit flag to indicate the parent
instead.
3.3. Permission Issues
The NFS protocol, strictly speaking, does not define the permission
checking used by servers. However, it is expected that a server will
do normal operating system permission checking using AUTH_UNIX style
Sun Microsystems, Inc. [Page 19]
RFC 1094 NFS: Network File System March 1989
authentication as the basis of its protection mechanism. The server
gets the client's effective "uid", effective "gid", and groups on
each call and uses them to check permission. There are various
problems with this method that can been resolved in interesting ways.
Using "uid" and "gid" implies that the client and server share the
same "uid" list. Every server and client pair must have the same
mapping from user to "uid" and from group to "gid". Since every
client can also be a server, this tends to imply that the whole
network shares the same "uid/gid" space. AUTH_DES (and the next
revision of the NFS protocol) uses string names instead of numbers,
but there are still complex problems to be solved.
Another problem arises due to the usually stateful open operation.
Most operating systems check permission at open time, and then check
that the file is open on each read and write request. With stateless
servers, the server has no idea that the file is open and must do
permission checking on each read and write call. On a local
filesystem, a user can open a file and then change the permissions so
that no one is allowed to touch it, but will still be able to write
to the file because it is open. On a remote filesystem, by contrast,
the write would fail. To get around this problem, the server's
permission checking algorithm should allow the owner of a file to
access it regardless of the permission setting.
A similar problem has to do with paging in from a file over the
network. The operating system usually checks for execute permission
before opening a file for demand paging, and then reads blocks from
the open file. The file may not have read permission, but after it
is opened it does not matter. An NFS server can not tell the
difference between a normal file read and a demand page-in read. To
make this work, the server allows reading of files if the "uid" given
in the call has either execute or read permission on the file.
In most operating systems, a particular user (on UNIX, the user ID
zero) has access to all files no matter what permission and ownership
they have. This "super-user" permission may not be allowed on the
server, since anyone who can become super-user on their workstation
could gain access to all remote files. The UNIX server by default
maps user id 0 to -2 before doing its access checking. This works
except for NFS root filesystems, where super-user access cannot be
avoided.
3.4. RPC Information
Authentication
The NFS service uses AUTH_UNIX, AUTH_DES, or AUTH_SHORT style
authentication, except in the NULL procedure where AUTH_NONE is
Sun Microsystems, Inc. [Page 20]
RFC 1094 NFS: Network File System March 1989
also allowed.
Transport Protocols
NFS is supported normally on UDP.
Port Number
The NFS protocol currently uses the UDP port number 2049. This is
not an officially assigned port, so later versions of the protocol
use the "Portmapping" facility of RPC.
3.5. Sizes of XDR Structures
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?