Requests For Comments ... for the community
Welcome to OpenRFC
Home Full RFC index RFC humour Our technology
<< Previous <<      RFC 409      >> Next >>    
Tenex interface to UCSB's Simple-Minded File System.
J.E. White. December 1972.

[Direct link][Download PDF version][Download text version]

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]


[Home] [Full RFC index] [RFC humour] [Our technology]

Copyright © Inter-Corporate Computer & Network Services, Inc.  All rights reserved.
All trademarks and RFC contents are the property of their respective owners.