RFC180 - File system questionnaire

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

Network Working Group Alex McKenzie

Request for Comments #180 BBN

NIC #7123 25 June 1971

Categories: D.7, G.3

Updates: none

Obsoletes: none

File System Questionnaire

As noted in RFC#164 (page 35), a subcommittee of the NWG, under the

chairmanship of Abhay Bhushan, is currently generating proposals for a

"data transfer protocol" and a "file transfer protocol".

The subcommittee has decided that the file transfer protocol should

provide standard methods for requesting the transfer of a file but

should not, at this time, attempt to standardize file naming

conventions, Access control conventions, and the like. Thus a user

who is, for example, trying to store a file on a remote Host will be

required to use the file naming conventions appropriate to the remote

Host.

Given the above point of view, it becomes imperative for users to have

some source of information about Host file conventions. SUCh

information, once compiled, will also serve as input to possible

standardization efforts of the file transfer subcommittee. For this

reason Abhay has asked me to solicit information on file conventions

from the Host organizations. What follows is a description of the

kinds of information of interest. I am well aware of the fact that

many of you are tired of writing system descriptions; Xerox copies of

short sections of your local documentation are fine if the result is

complete and comprehensible. (In the case that your Host will never

permit network use of your file system, a note to that effect would be

sufficient.)

Information Requested

1. File naming conventions - We (loosely) define a pathname to be

the data string which must be input to the file system by a user

(a network user if your system makes a distinction between local

and network users) in order to identify a file. We are interested

in syntax, semantics, and defaults. Typical components of pathnames

are:

- "device" fields

- user names

- version numbers

- index names

- punctuation marks

- device is disk

- version number is largest in system

For hierarchical file structures, descriptions may be fairly

complex, but with lots of defaults; in such cases an illustration

of a "normal" pathname might be helpful.

2. Access control mechanisms - Access control mechanisms range from

simply knowledge of a file's pathname to elaborate hierarchies

of group-project-task-username membership with passWords and

separate controls for reading and writing. There are two

ASPects of the access control mechanism which are of interest:

a. A description of what inputs the user should give the file

system, both at the time of file creation and at the time of

retrieval, in order to define the permitted modes of access

and to gain access. What are the syntax and semantics of

these inputs?

b. A description of the ways in which the access control

mechanism is designed to help (or hinder) the sharing of

files. For example, may two users "simultaniously" update a

given file? May the creator of the file define a set of

authorized users to the file system (and how)? Is it possible

to define different access controls for various subunits of a

given file?

3. Directories - Many systems maintain file directories which are

designed to be helpful to the user. A directory might, for

example, provide a list of all files created by a particular

individual, along with some information regarding file size,

file structure, access controls, etc. In general, such systems

allow the user to input a pathname and retrieve the directory to

which that pathname refers. Aspects of the directory structure of

interest are:

a. What are the syntax and semantics of a directory pathname?

b. What use is a directory, i.e., what type of information

does the directory contain?

c. What access controls are used for access to the directories?

For example, must a user supply a password in order to

retrieve a directory, and is this password typically the same

as the password he would use to retrieve a file listed in that

directory.

[Page 2]

4. Commands and functions of the file system - A general description

of what the file system is designed to do would be useful. For

example, the system might simply accept an entire file and store

it sequentially on a tape; with the only mode of retrieval being

to retrieve the entire file. On the other hand, the system might

provide the ability to access any "subfield" with a unique

pathname. Perhaps there is the ability to restructure a file,

change the access control, delete all the fields associated with a

directory, etc. We realize that this aspect of the file system

begins to overlap the area of "data management", which is the

responsibility of another subcommittee; therefore, use your

judgement as to what functions are an intrinsic aspect of the

file-handling system and which are aspects of "data-management".

5. Internal representation and I/O modes - The remote user of a file

system will normally be interested in internal representation of

data only insofar as that representation of data is reflected in

the I/O interface between the file system and the network. For

example, if all of the file system's I/O is in 8-bit ASCII

characters, then the user is unlikely to care if they are stored

in ASCII, EBCDIC, or some other form. However, if an alternate

transmission mode is available it may be useful; for example,

two PDP-10's, both of which store 5 characters and one "filler"

bit per word, might find it advantageous to transfer information

in this mode rather than converting between internal representation

and 8-bit ASCII for each character. Other information on internal

representation which would be of interest to the user might

include (if applicable):

- range of numeric data permitted

- maximum text string lengths

- whether the user must indicate "record" boundaries on input

- what "logical structure" information the user may specify

for a new file, and what he must specify

- whether the user must specify the file size before beginning

input, and how he does it

6. UndouBTedly, there will be aspects of each file system which don't

fit neatly into the categories above, but which users will find

important or essantial in using the system. These should be

identified and described if possible.

Please address responses to this questionnaire to:

Alex McKenzie

Bolt Beranek and Newman Inc.

50 Moulton Street

Cambridge, Massachusetts 02138

[Page 3]

If the questions above are confusing, don't hesitate to call me for

clarification at (617) 491-1850 ext. 441. I will issue another RFC

summarizing the responses after I have received a significant number

of them.

[ This RFCwas put into machine readable form for entry ]

[ into the online RFCarchives by Stefan Hinker 6/97 ]

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
 
 
© 2005- 王朝網路 版權所有 導航