|
|
|
|
|
IETF RFC 409
Tenex interface to UCSB's Simple-Minded File System
Last modified on Thursday, November 8th, 2001
Permanent link to RFC 409
Search GitHub Wiki for RFC 409
Show other RFCs mentioning RFC 409
Network Working Group J. White
Request for Comments: 409 SRI-ARC
NIC: 12401 8 December 1972
Related RFCs: 122, 399
TENEX Interface To UCSB's Simple-Minded File System
I. PREFACE
A subsystem for TENEX called SMFS has been written to interface
ARPANET TENEX users to the Simple-Minded File System at UCSB-MOD75
(see NIC 5834 / RFC 122 and NIC 11917 / RFC 399). The Simple-Minded
File System is a resident server process at UCSB which currently
manages approximately 10K pages of on-line, direct-access storage.
Using the simple command language or the subsystem here described,
the user can transfer files to and from UCSB, and delete and rename
them while they reside at Santa Barbara. Files stored at UCSB may be
read and/or write protected, and a file archived to UCSB from the
TENEX system can be retrieved from another.
This document is intended to provide users with the information
necessary to use SMFS from a terminal; the reader is assumed familiar
with TENEX.
SMFS is currently installed at SRI-ARC (note in particular that the
ARC EXEC WILL NOT give the user any 'GENERAL SUBSYSTEMS NOT AVAILABLE
FOR NIC USE' flack about invoking SMFS).
Copies of the source file are available upon request from the NIC.
Bug reports and comments upon the code and documentation are
solicited by the author, and may be sent to JEW through the Journal.
II. LIMITATIONS
SMFS can archive at Santa Barbara any file resident in a TENEX file
system except:
(1) Long files (in the strict, TENEX sense), and
(2) Files whose directory name, filename, or extension contains
other than alphameric characters, or whose combined length
exceeds 32 characters (this limitation arises because of
naming restrictions imposed at UCSB).
White PAGE 1
RFC 409 TENEX INTERFACE TO SIMPLE-MINDED FILE SYSTEM December 1972
III. OPERATING INSTRUCTIONS
SMFs is invoked like any other subsystem --- by typing its name
followed by a carriage return (CR). SMFS responds with the herald
'UCSB Archival System (ver n date)' followed by its prompt character
'#'. Whenever SMFS types its prompt character, it expects the user
to respond with a command ('?' will generate a list of all valid
commands).
The user selects a command by typing its first letter (here and
throughout the exchange, upper- and lower-case alphabetics are
interchangeable). SMFS acknowledges a command it recognizes by
typing the remaining characters of the keyword, and rejects those it
doesn't by typing '?'.
If the command requires arguments, SMFS prompts the user for each one
in turn by describing it in parentheses. If the argument is a
keyword, SMFS will list the set of alternatives (separated by
slashes). The user selects one by typing its first letter. Again,
SMFS acknowledges a valid selection by completing it; if the user's
response is in error, SMFS prompts for the parameter a second time.
If the argument is not a keyword (e.g., a filename), the user enters
an appropriate character string terminated by a CR. Commands with no
predicate are simply confirmed by the user with a CR.
Entering the last argument initiates execution of the command. In
most cases, successfully executed commands illicit no explicit
response (SMFS simply prompts for the next command). Unsuccessful
commands illicit a diagnostic.
IV. COMMAND EDITING
Anytime a character string is called for, the following editing
features are available to the user:
control-A deletes the previous character
control-X deletes the entire string
Control-R retypes the string
Anytime a filename (see Section V) is called for, the following
additional editing features are available:
control-W deletes the current field
control-F recognizes the current field
ESC recognizes all remaining fields
Control-O aborts a command during specification or execution (some
commands cannot be aborted once the final CR has been typed).
White PAGE 2
RFC 409 TENEX INTERFACE TO SIMPLE-MINDED FILE SYSTEM December 1972
V. FILE SPECIFICATION
Whenever SMFS solicits a filename from the user, either of the
following is acceptable:
(1) hostname : filename
'Hostname' is a standard host name or decimal host address
identifying the host to which the file at UCSB belongs (to
distinguish, for example, the directory <SUBSYS> at SRI-ARC
from the directory <SUBSYS> at USC-ISI).
If unspecified, the host name defaults to that of the TENEX
system from which SMFS is invoked (and in this case the
delimiting ':' must be dropped).
Note that 'hostname' need be specified only in connection with
inter-TENEX file transfers, and CANNOT be specified as part of
the local filename in a MOVE or COPY command.
'Filename' is a standard TENEX filename (subject to the
constraints of Section II).
If no directory is specified, that to which the user is
currently connected is taken as the default.
If name, extension, or version number is left unspecified, it
defaults to the one most recently specified.
(2) ESC (i.e., Altmode)
ESC in this context denotes the most recent file
specification, which SMFS will retype for the user.
VI. SYNTAX CONVENTIONS
In the description which follows, the following syntax conventions
are employed:
Characters which must be entered literally by the user are
represented in upper-case (although they may be either in upper-
or lower-case when typed by the user).
Variables (like filenames) which must be entered by the user are
represented by their generic names in lower case (although they
may be either in upper- or lower-case when typed by the user).
White PAGE 3
RFC 409 TENEX INTERFACE TO SIMPLE-MINDED FILE SYSTEM December 1972
The following special symbols represent control characters entered
by the user:
CR --carriage return or Telnet new-line
SP --space
ESC --alt mode or escape
Output from the system is distinguished by enclosing it in square
brackets.
Whenever an element in the user-system exchange can take more than
one value, the alternatives are listed vertically in a column.
VII. COMMAND DESCRIPTIONS
A. USER NAME AND ACCOUNT
UCSB identifies users of its Simple-Minded File System by:
(1) user name --
a character string of from one to eight alphameric characters
of SP, and
(2) account --
a character string of from one to four alphameric characters
or SP.
SMFS maintains internally a pair of accumulators. One contains a
user name, the other an account, each either a character string
specified explicitly by the user or an SMFS-supplied default (the
user's TENEX login directory name and 'l', respectively). Both
accumulators are set initially to their default values.
Note: If the user's login directory name exceeds eight characters in
length, the user must explicitly supply a user name; no default is
available.
Whenever SMFS interacts with the server process at Santa Barbara on
the user's behalf, it does so with the accounting parameters then in
the accumulators.
White PAGE 4
RFC 409 TENEX INTERFACE TO SIMPLE-MINDED FILE SYSTEM December 1972
The user sets and inspects the user name and account with the USER
NAME and ACCOUNT commands:
U[ser name]
[[currentusername]] newusername CR
SP [logindirectoryname]
CR
A[ccount]
[[currentaccount]] newaccount CR
SP [1]
CR
USER NAME and ACCOUNT display and optionally change the contents of
the user name and account accumulators, respectively:
If 'newusername' or 'newaccount' is specified, it replaces the
current contents of the appropriate accumulator.
If SP is specified, the accumulator is set to the appropriate
default.
If CR is typed, the user name or account is left unchanged.
B. COPY
The COPY command effects the transfer of a copy of a file to or from
UCSB. The file which is the source of the copy remains unmodified;
the user must have read access to it. The syntax of the command is
one of the following, depending upon the direction of transfer:
C[opy]
[(to/from UCSB] T[o]
[(file)] localfilespec CR
[(store as file)] remotefilespec CR
[(create/replace)] C[reate]
R(eplace]
C[opy]
[to/from UCSB] F[rom]
[(file)] remotefilespec CR
[(store as file)] localfilespec CR
where 'localfilespec' and 'remotefilespec' are as defined in
Section V.
White PAGE 5
RFC 409 TENEX INTERFACE TO SIMPLE-MINDED FILE SYSTEM December 1972
Note that a file can effectively be renamed in transit between TENEX
and UCSB by specifying 'localfilespec' different from
'remotefilespec'. The more common situation is that in which the
second of the two filespec's is simply ESC. In 'localfilespec', the
field-defaulting algorithms of Section V are not applied; the normal
TENEX defaults are applicable.
If in a copy to UCSB the user specifies 'create'; SMFS will ignore
the command (and so inform the user) if a file of the same name
already exists at UCSB. If 'replace' is specified, the command will
be ignored if a file of the same name DOESN'T already exist at UCSB.
Also, if 'replace' is specified, the user must have write access to
the existing file at UCSB.
C. MOVE
The MOVE command functions like COPY except that the source file for
the operation is deleted once it has been transferred successfully.
The user must have both read and write access to the source file.
D. LOCATE
The LOCATE command verifies the existence of a file at UCSB. Its
syntax is
L[ocate (file)] filespec CR
[Archived at UCSB]
[Not Archived at UCSB]
Neither read nor write access to the designated file is required.
Note: LOCATE is the nearest thing to a TENEX DIRECTORY command
available. A full DIRECTORY command cannot currently be implemented
because of restrictions imposed at UCSB.
E. DELETE
The DELETE command deletes and releases all secondary storage
assigned to a file previously copied or moved to UCSB:
D[elete (file)] filespec CR
The user must have write access to the file at UCSB.
White PAGE 6
RFC 409 TENEX INTERFACE TO SIMPLE-MINDED FILE SYSTEM December 1972
F. RENAME
The RENAME command changes the name of a file residing at UCSB as the
result of a previous move or copy operation:
R[ename (file)] filespec CR
[(new file)] newfilespec CR
The user must have write access to the file at UCSB, and no file may
already exist there with the name 'newfilespec'.
G. PASSWORD
While files reside at UCSB, they may be protected from unauthorized
access or modification by the assignment of a read and/or write
password, respectively. Each is a character string of from one to 36
alphameric characters or SP.
SMFS maintains internally a pair of accumulators. One is always
either empty or containing a read password, the other empty or
containing a write password (both accumulators are initially empty).
Whenever a command issued by the user requires (always implicitly) a
password(s), the one then contained in the appropriate accumulator is
applied. An empty accumulator implies 'no password'.
The user sets and inspects the two passwords with the PASSWORD
command:
P[assword]
[(read/write)] R[ead]
W[rite]
[[currentpassword]] newpassword CR
SP [none]
CR
PASSWORD displays and optionally changes the contents of one of the
two password accumulators:
If 'new password' is specified, it replaces the current contents
of the accumulator.
If SP is specified, the accumulator is made empty.
If CR is typed, the password is left unchanged.
White PAGE 7
RFC 409 TENEX INTERFACE TO SIMPLE-MINDED FILE SYSTEM December 1972
H. NEWS
The NEWS command prints at the user's terminal the contents of the
file:
SRI-ARC: <SYSTEM >SMFS.NEWS1
residing at UCSB. SRI-ARC maintains this file, and as necessary
places in it information (e.g., command syntax changes) of concern to
users of UCSB's archiving service. Should the user, for example,
have difficulty with any of the commands described in this document,
NEWS is a good starting point for obtaining help.
The command has the syntax:
N[ews] CR
If the news file is long, SMFS will periodically pause and type
'Continue?'. The user may then respond 'N' to halt printout, or 'Y'
or CR to continue (of course, control-O will abort printout at any
time).
I. QUIT
The QUIT command causes SMFS to return to the EXEC:
Q[uit] CR
[This RFC was put into machine readable form for entry]
[into the online RFC archives by Helene Morin, Via Genie 12/99]
White PAGE 8
Tenex interface to UCSB's Simple-Minded File System
RFC TOTAL SIZE: 14231 bytes
PUBLICATION DATE: Thursday, November 8th, 2001
LEGAL RIGHTS: The IETF Trust (see BCP 78)
|