Lines Matching full:file
10 .OH 'Network File System: Version 2 Protocol Specification''Page %'
11 .EH 'Page %''Network File System: Version 2 Protocol Specification'
14 \&Network File System: Version 2 Protocol Specification
16 .IX "Network File System" "" "" "" PAGE MAJOR
18 .IX "Network File System" "version-2 protocol specification"
41 attach remote directory trees to some local file system.
93 directories that inherently have state -- what good would a file be
114 NFS assumes a file system that is hierarchical, with directories as
115 all but the bottom-level files. Each entry in a directory (file,
120 file names) in the name. A "file system" is a tree on a single
123 all file systems appear as a single tree, while others maintain a
124 "forest" of file systems. Files are unstructured streams of
126 file system model.
130 the directories, and return a file handle when it is done. There are
177 /* \fIThe maximum number of bytes in a file name argument\fP */
183 /* \fIThe size in bytes of the opaque file handle\fP */
234 No such file or directory. The file or directory
245 File exists. The file specified already exists.
255 File too large. The operation caused a file to grow
263 File name too long. The file name in an operation was too long.
272 That is, the file referred to by that file handle no longer exists,
296 gives the type of a file. The type
298 indicates a non-file,
300 is a regular file,
319 is the file handle passed between the server and the client.
320 All file operations are done using file handles to refer to a file or
321 directory. The file handle can contain whatever information the server
322 needs to distinguish an individual file.
364 structure contains the attributes of a file; "type" is the type of
365 the file; "nlink" is the number of hard links to the file (the number
366 of different names for the same file); "uid" is the user
367 identification number of the owner of the file; "gid" is the group
368 identification number of the group of the file; "size" is the size in
369 bytes of the file; "blocksize" is the size in bytes of a block of the
370 file; "rdev" is the device number of the file if it is type
374 "blocks" is the number of blocks the file takes up on disk; "fsid" is
375 the file system identifier for the filesystem containing the file;
376 "fileid" is a number that uniquely identifies the file within its
377 filesystem; "atime" is the time when the file was last accessed for
378 either read or write; "mtime" is the time when the file data was last
380 file was last changed. Writing to the file also changes "ctime" if
381 the size of the file changes.
384 file type is specified both in the mode bits and in the file type.
395 0020000&This is a character special file; "type" field should be NFCHR.
396 0060000&This is a block special file; "type" field should be NFBLK.
397 0100000&This is a regular file; "type" field should be NFREG.
398 0120000&This is a symbolic link file; "type" field should be NFLNK.
418 system call in the UNIX system. The file type is specified both in
419 the mode bits and in the file type. This is fixed in future
444 structure contains the file attributes which can be set
447 above. A "size" of zero means the file should be truncated.
460 is used for passing file names or pathname components.
493 attributes of the file on which the operation was done.
509 "fhandle" "dir" is the directory in which to find the file "name".
520 fhandle file;
530 structure. If the call succeeded, a new file handle "file" and the
531 "attributes" associated with that file are returned along with the
548 filesystem information blocks (such as indirect blocks), and file
562 * Remote file service routines
601 \&Get File Attributes
611 the attributes for the file given by the input fhandle.
614 \&Set File Attributes
618 fhandle file;
627 are the new value for the attributes of "file". If the reply
631 the file after the "SETATTR" operation has completed.
645 root file handle of a filesystem requires moving pathnames between
648 function of looking up the root file handle is done by the
655 \&Look Up File Name
664 then the reply "file" and reply
665 "attributes" are the file handle and attributes for the file "name"
686 the symbolic link given by the file referred to by the fhandle argument.
694 \&Read From File
698 fhandle file;
716 Returns up to "count" bytes of "data" from the file given by
717 "file", starting at "offset" bytes from the beginning of the file.
718 The first byte of the file is at offset zero. The file attributes
735 \&Write to File
739 fhandle file;
751 "file". The first byte of the file is at offset zero. If the
753 attributes of the file after the write has completed. The write
762 \&Create File
774 The file "name" is created in the directory given by "dir". The
775 initial attributes of the new file are given by "attributes". A
776 reply "status" of NFS_OK indicates that the file was created, and
777 reply "file" and reply "attributes" are its file handle and
779 failed and no file was created.
782 "create the file only if it is not already there".
785 \&Remove File
792 The file "name" is removed from the directory given by "dir". A
798 \&Rename File
810 The existing file "from.name" in the directory given by "from.dir"
814 the file was renamed. The
822 \&Create Link to File
834 Creates the file "to.name" in the directory given by "to.dir",
835 which is a hard link to the existing file given by "from". If the
843 to a file, the attributes for the file should have a value for
862 Creates the file "from.name" with ftype
865 given by "from.dir". The new file contains the pathname "to" and
872 A symbolic link is a pointer to another file. The name given in
874 created file. When the client references a file that is a symbolic
894 directory was created, and reply "file" and reply "attributes" are
895 its file handle and attributes. Any other reply "status" means
952 which consists of a unique number to identify the file within a
953 filesystem, the "name" of the file, and a "cookie" which is an
961 "fileid" in the attributes of the file. (See the
992 attributes for the filesystem that contains file referred to by the
1015 operations have semantics similar to the operations of the UNIX file
1028 process can open a file and, while it is open, remove it from the
1029 directory. The file can be read and written as long as the process
1030 keeps it open, even though the file has no name in the filesystem.
1032 The client can do some tricks such as renaming the file on remove,
1034 enough functionality to implement most file system semantics on the
1086 that the file is open on each read and write request. With stateless
1087 servers, the server has no idea that the file is open and must do
1089 filesystem, a user can open a file and then change the permissions so
1091 to the file because it is open. On a remote filesystem, by contrast,
1093 permission checking algorithm should allow the owner of a file to
1096 A similar problem has to do with paging in from a file over the
1098 before opening a file for demand paging, and then reads blocks from
1099 the open file. The file may not have read permission, but after it
1101 difference between a normal file read and a demand page-in read. To
1103 in the call has execute or read permission on the file.
1116 Various file system parameters and options should be set at mount
1119 provided. Soft mounted file systems return errors when RPC
1121 while hard mounted file systems continue to retransmit forever.
1136 protocol to get the first file handle, which allows them entry into a
1182 /* \fIThe size in bytes of the opaque file handle\fP */
1202 is the file handle that the server passes to the
1203 client. All file operations are done using file handles to refer
1204 to a file or directory. The file handle can contain whatever
1205 information the server needs to distinguish an individual file.
1227 the call completed successfully, and a file handle for the
1304 file handle for the directory "dirname". This file handle may be