📄 rfc1037.txt
字号:
Greenberg & Keene [Page 22]
RFC 1037 NFILE - A File Access Protocol December 1987
The connection-identifier informs the user of the correct identity of
the logical port that the server has provided. NFILE expects the
connection-identifier to be a string. For TCP this string is the
port number represented in decimal. For Chaosnet, this string is the
contact name. The connection-identifier is used only once; in all
subsequent NFILE commands that need to reference either of the data
channels that constitute this data connection, the new-input-handle
and new-output-handle are used.
For background information: See the section "NFILE Control and Data
Connections", section 4.
8.9 DELETE Command
Command: (DELETE tid handle pathname)
Response: (DELETE tid)
DELETE deletes a file on the remote file system.
Either a handle or a pathname must be supplied, but not both. If
given, the handle must be a data channel handle for a data stream
opening, or a direct file identifier for a direct access opening.
pathname is a string in the full pathname syntax of the server host.
See the section "Syntax of File and Directory Pathname Arguments",
section 7.4.
With a pathname supplied, the DELETE command causes the specified
file to be deleted. DELETE has different results depending on the
operating system involved. That is, DELETE causes soft deletion on
TOPS-20 and LMFS, and hard deletion on UNIX and Multics. If an
attempt is made to delete a delete-through link on a Symbolics LMFS,
its target is deleted instead.
If the handle argument is supplied to DELETE, the server deletes the
open file bound to the data channel specified by handle at close
time. This is true in both the output and input cases.
8.10 DIRECT-OUTPUT Command
Command: (DIRECT-OUTPUT tid direct-handle output-handle)
Response: (DIRECT-OUTPUT tid)
DIRECT-OUTPUT starts and stops output data flow for a direct access
file opening. DIRECT-OUTPUT explicitly controls binding and
unbinding of an output data channel to a direct access opening.
Greenberg & Keene [Page 23]
RFC 1037 NFILE - A File Access Protocol December 1987
direct-handle is a required argument, and output-handle is optional.
If supplied, output-handle is a request to bind an output data
channel (indicated by output-handle) to the direct access opening
designated by the direct-handle. The specified output data channel
must be free. The server binds the data channel and begins accepting
data from that connection and writing it to the opening.
If the output-handle is omitted, this is a request to unbind the
channel and terminate the active output transfer.
8.11 DIRECTORY Command
Command: (DIRECTORY tid input-handle pathname control-keywords
properties)
Response: (DIRECTORY tid)
DIRECTORY returns a directory listing including the identities and
attributes for logically related groups of files, directories, and
links. If the command is successful, a single token list containing
the requested information is sent over the data channel specified by
input-handle, and the data channel is then implicitly freed by both
sides <2>. For details on the format of the token list: See the
section "NFILE DIRECTORY Data Format", section 8.11.1.
pathname specifies the files that are to be described; it is a string
in the full pathname syntax of the server host. See the section
"Syntax of File and Directory Pathname Arguments", section 7.4.
The pathname generally contains wildcard characters, in operating-
system-specific format, describing potential file name matches. Most
operating systems provide a facility that accepts such a pathname and
returns information about all files matching this pathname. Some
operating systems allow wildcard (potential multiple) matches in the
directory or device portions of the pathname; other operating systems
do not. There is no clear contract at this time about what is
expected of servers on systems that do not allow wildcard matches (or
some kinds of wild card matches), when presented with a wildcard.
properties is a token list of keywords that are the names of
properties. If properties is omitted or supplied as the empty token
list, the server sends along all properties. If any properties are
supplied, the user is requesting the server to send only those
properties.
Greenberg & Keene [Page 24]
RFC 1037 NFILE - A File Access Protocol December 1987
control-keywords ARGUMENT TO DIRECTORY
control-keywords is a token list of keywords. The control-keywords
affect the way the DIRECTORY command works on the server machine.
Although some of the options below request the server to limit (by
some filter) the data to be returned, it is never an error if the
server returns more information than is requested.
The following keywords are recognized:
DELETED
Includes soft-deleted files in the directory list. Without this
option, they must not be included. Such files have the DELETED
property indicated as true" among their properties. DELETED is
ignored on systems that do not support soft deletion.
DIRECTORIES-ONLY
This option changes the semantics of DIRECTORY fairly drastically.
Normally, the server returns information about all files,
directories, and links whose pathnames match the supplied pathname.
This means that for each file, directory, or link to be listed, its
directory name must match the potentially wildcarded) directory name
in the supplied pathname, its file name must match the file name in
the supplied pathname, and so on.
When DIRECTORIES-ONLY is supplied, the server is to list only
directories, not whose pathnames match the supplied pathname, but
whose pathnames expressed as directory pathnames match the
(potentially wildcarded) directory portion of the supplied pathname.
The description of the PROBE-DIRECTORY keyword that can be supplied
as the direction argument of the OPEN command discusses this: See
the section "OPEN Command", section 8.20.
It is not yet established what servers on hosts that do not support
this type of action natively are to do when presented with
DIRECTORIES-ONLY and a pathname with a wildcard directory component.
FAST Speeds up the operation and data transmission by not listing any
properties at all for the files concerned; that is, only the
truenames are returned.
Greenberg & Keene [Page 25]
RFC 1037 NFILE - A File Access Protocol December 1987
NO-EXTRA-INFO
Specifies that the server is to suppress listing those properties
that are generally more difficult or expensive to obtain. This
typically eliminates listing of directory-specific properties such as
information about default generation counts and expunge dates.
SORTED
This causes the directory listing to be sorted. The sorting is done
alphabetically by directory, then by file name, then file type, then
file version (by increasing version number).
8.11.1 NFILE DIRECTORY Data Format
If the NFILE DIRECTORY command completes successfully, a single token
list containing the requested directory information is sent on the
data channel specified by the input-handle argument in the DIRECTORY
command. This section describes the format of that single token
list, and gives further detail on the properties argument to
DIRECTORY.
The token list is a top-level token list, so it is delimited by TOP-
LEVEL-LIST-BEGIN and TOP-LEVEL-LIST-END. The top-level token list
contains embedded token lists. The first embedded token list
contains the empty token list followed by property/value pairs
describing property information of the file system as a whole rather
than of a specific file. NFILE requires one property of the file
system to be present: DISK-SPACE-DESCRIPTION is a string describing
the amount of free file space available on the system. The following
embedded token lists contain the pathname of a file, followed by
property/value pairs describing the properties of that file.
The following example shows the format of the top-level token list
returned by DIRECTORY, for two files. It is expected that the server
return several property/value pairs for each file; the number of
pairs returned is not constrained. In this example, two
property/value pairs are returned for the file system, two pairs are
returned for the first file, and only one pair is returned for the
second file.
TOP-LEVEL-LIST-BEGIN
LIST-BEGIN - first embedded token list starts
LIST-BEGIN - an empty embedded token list starts
LIST-END - the empty embedded token list ends
prop1 value1 - property/value pairs of file system
prop2 value2
LIST-END
Greenberg & Keene [Page 26]
RFC 1037 NFILE - A File Access Protocol December 1987
LIST-BEGIN
pathname1 - pathname of the first file
prop1 value1 - property/value pairs of first file
prop2 value2
LIST-END
LIST-BEGIN
pathname2 - pathname of the second file
prop1 value1 - property/value pairs of second file
LIST-END
TOP-LEVEL-LIST-END
The following example is designed to illustrate the structure of the
top-level token list by depicting TOP-LEVEL-LIST-BEGIN and TOP-
LEVEL-LIST-END by parentheses and LIST-BEGIN and LIST-END by squarbe
rackets. respectively. The indentation, blank spaces, and newlines
in the example are not part of the token list, but are used here to
make the structure of the token list clear.
([ [ ] prop1 value1 prop2 value2]
[pathname1 prop1 value1 prop2 value2]
[pathname2 prop1 value1])
The pathname is a string in the full pathname syntax of the server
host. See the section "Syntax of File and Directory Pathname
Arguments", section 7.4.
For further information on file property/value pairs: See the
section "Format of NFILE File Property/Value Pairs", section 7.5.
8.12 DISABLE-CAPABILITIES Command
Command: (DISABLE-CAPABILITIES tid capability)
Response: (DISABLE-CAPABILITIES tid cap-1 success-1
cap-2 success-2 cap-3 success-3 ...)
DISABLE-CAPABILITIES causes an access capability to be disabled on
the server machine. capability is a string naming the capability to
be disabled. The meaning of the capability is dependent on the
operating system.
The return values cap-1, cap-2, and so on, are strings specifying
names of capabilities. If the capability named by cap-1 was
successfully disabled, the corresponding success-1 is supplied as
Boolean truth; otherwise it is the empty token list.
Greenberg & Keene [Page 27]
RFC 1037 NFILE - A File Access Protocol December 1987
Although the user can specify only one capability to disable, it is
conceivable that the result of disabling that particular capability
is the disabling of other, related capabilities. That is why the
command response can contain information on more than one capability.
8.13 ENABLE-CAPABILITIES Command
Command: (ENABLE-CAPABILITIES tid capability password)}
Response: (ENABLE-CAPABILITIES tid cap-1 success-1
cap-2 success-2 cap-3 success-3 ...)
ENABLE-CAPABILITIES causes an access capability to be enabled on the
server machine. The password argument is optional, and should be
included only if it is needed to enable this particular capability.
Both password and capability are strings. The meaning of the
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -