ISO 8571-2:1988/Amd 1:1992
(Amendment)Information processing systems — Open Systems Interconnection — File Transfer, Access and Management — Part 2: Virtual Filestore Definition — Amendment 1: Filestore Management
Information processing systems — Open Systems Interconnection — File Transfer, Access and Management — Part 2: Virtual Filestore Definition — Amendment 1: Filestore Management
Amends Introduction, clauses and subclauses 1, 5, 6, 9.1, 9.5, 12, 13.2, 13.9, 13.11, 13.12, 14, 14.1 to 14.5, 15, adds subclauses 5a, 6.1, 7a, 9a to 9d, 11a to 11c, 12a, 13.13 to 13.20.
Systèmes de traitement de l'information — Interconnexion de systèmes ouverts — Transfert, accès et gestion de fichiers — Partie 2: Détermination du système de fichiers virtuel — Amendement 1: Gestion du système de fichiers
General Information
Relations
Standards Content (Sample)
INTERNATIONAL
STANDARD 857 I-2
First edition
1988-IO-01
AMENDMENT 1
1992-12-15
Information processing systems - Open Systems
Interconnection - File Transfer, Access and
Management -
Part2:
Virtual Filestore Definition
AMENDMENT 1 : Filestore Management
Technologies de /‘information - lnterconnexion de systemes ouverts (OS/) -
Transfert, acctk et gestion de tkhiers -
Partie 2: Dkfinition du systkme de fichiers virtue/
AMENDEMENT I : Gestion du systhme de fichiers
- -
= =
IT =
= Z
: ;
1
5
II
=
=
Reference number
:a
IS0 8571-2:1988/Amd.1:1992 (E)
---------------------- Page: 1 ----------------------
IS0 857192:1988/Amd.1:1992 (E)
Foreword
IS0 (the International Organization for Standardization) and IEC (the International
Electrotechnical Commission) form the specialized system for worldwide
standardization. National bodies that are members of IS0 or IEC participate in
the development of International Standards through technical committees
established by the respective organization to deal with particular fields of
technical activity. IS0 and IEC technical committees collaborate in fields of
mutual interest. Other international organizations, governmental and non-
governmental, in liaison with IS0 and IEC, also take part in the work.
In the field of information technology, IS0 and IEC have established a joint
technical committee, lSO/IEC JTC 1. Draft International Standards adopted by the
joint technical committee are circulated to national bodies for voting. Publication
as an International Standard requires approval by at least 75 % of the national
bodies casting a vote.
Amendment 1 to International Standard IS0 8571-21988 was prepared by Joint
Technical Committee lSO/IEC JTC 1, Information technology.
IS0 8571-2 consists of the following parts, under the general title information
Open Systems Interconnection - File Transfer, Access and
processing systems -
Management
- Part 7 : General introduction
- Part 2 : Virtual Filestore Definition
- Part 3 : File Service Definition
- Part 4 : File Protocol Specification
- Part 5 : Protocol Implementation Conformance Statement Proforma
0 lSO/IEC 1992
All rights reserved. No part of this publication may be reproduced or utilized in any form or by
any means, electronic or mechanical, including photocopying and microfilm, without
permission in writing from the publisher.
0
lSO/IEC Copyright Off ice Case postale 56 l CH-1211 Geneve 20 l Switzerland
Printed in Switzerland
ii
---------------------- Page: 2 ----------------------
IS0 857%2:1988/Amd.1:1992 (E)
Information processing systems - Open Systems
Interconnection - File Transfer, Access and Management -
Part2
Virtual Filestore Definition
AMENDMENT 1 : Filestore Management
NOTE - This amendment has additional subclauses and tables to IS0 8571 which are indicated by the use of lower case
Roman letters beginning with “a” and imply ordering alphabetically, following the clause with the same numerical value in
IS0 8571. These and all subsequent subclauses, tables, and cross references will be renumbered in subsequent editions.
1 Scope and field of application
Introduction
(amend 1st paragraph)
(amend 3rd paragraph, page 1)
This part of IS0 8571
IS0 8571 defines services for file transfer, access and
It also specifies a protocol available
management.
a) defines an abstract model of the virtual filestore
within the application layer of the Reference Model.
for describing files and filestores (see section
The service defined is of the category Application
one);
Service Element (ASE). It is concerned with
identifiable bodies of information which can be treated b) defines the set of Actions available to manipulate
as files, stored and managed within open systems, or the elements of the model (see section two);
passed between application processes.
c) defines the properties of individual objects and
(amend 4th paragraph, page I) associations in terms of attributes (see section
three).
IS0 8571 defines a basic file service. It provides
defines the form of representations of files
sufficient facilities to support file transfer, file access,
d)
and management of files stored on open systems. with hierarchical structures (see clause 7 in
IS0 8571 does not specify the interfaces to a file section one).
transfer, access or management facility within the local
system.
---------------------- Page: 3 ----------------------
IS0 8571-2:1988/Amd.l:1992 (E)
Section one: The filestore model
5 Basic concepts 5a The virtual filestore model
5a.l Fliestore Objects
(amend 3rd paragraph (atier note), page 2)
A filestore may contain an arbitrary number (greater A virtual filestore is comprised of one or more of three
than or equal to one) of objects (see figure 1). kinds of objects:
files;
(amend 4th paragraph, page 2)
a)
The properties of each object are defined by the file-directories;
b)
values of a set of object attributes. These attributes
references.
C)
are global; at any one time, a single attribute value is
available to all initiators. Different object types may 5a.l .I Files
have distinct types of attributes, as well as types of
File objects contain data, and provide structuring
attributes in common.
information to access the data within them (see clause
(add following paragraph 5, page 2) .
7)
Each file-directory maintains a parenthood relationship 5a.l.2 File-directories
with zero or more subordinate objects. Some of the
File-directory objects maintain a set of relationships to
file-directory attributes may identify access control
zero or more other objects within the filestore, whether
information to subordinate objects.
those objects are files, references, or other file-
Each reference maintains a link to exactly one other directories. This relationship is parenthood. A file-
object. The referent is either a file or a file-directory. directory is said to be the parent of an object if it
The identity of the referent is available as an attribute maintains the relationship of parenthood for that
of the reference, in the form of a (possibly incomplete) object. Similarly, an object is said to be the child of a
primary pathname. This attribute can not be changed. specified directory if that directory is the object’s
Other reference attributes may identify the object type parent. In this way, file-directories provide a means of
and access control information to the linked object. If grouping objects within the virtual filestore. These
the identity of the referent changes, the corresponding groups can then be used to provide a structural order
reference ceases to exist (the filestore tree) to the data files within the filestore.
(amend 7th paragraph, page 3) An object is ‘in’ a file-directory if either
The first are in one to one correspondence with the a) that file-directory is the parent of the object
object attributes, and indicate the active value of those
b) there is a reference who’s parent is the file-
attributes as perceived by the initiator.
directory, linking to the object.
(amend 9th paragraph, pages 3 and 4)
An object is ‘under’ a file-directory if either
An arbitrary number (greater than or equal to zero) of
a) the object is in the file-directory
initiators may have initialized FTAM regimes at any
one time. Exchanges between the initiator and the b) the object is in another file-directory that is under
(Note this is a recursive
responder lead to the selection of at most one object in the file-directory.
definition. )
the responder’s virtual filestore to be bound to a
particular RAM regime at any one time. Note that
5a.l.3 References
multiple file objects may be identified for later selection
via the generalized selection service. However only Reference objects maintain exactly one relationship to
That -
one object may be selected at a time. Further, no exactly one other object within the filestore.
guarantees are placed on the availability of any file relationship is linkage. The object % linked by the
object in this group if it is eventually selected. reference must be either a file or a file-directory. The
structure defined by the parent and linkage relations is
(add after clause 5, page 4)
called the filestore structure.
2
---------------------- Page: 4 ----------------------
IS0 8571-2:1988/Amd.l:1992 (E)
5a.2 Filestore structure Objects within a virtual filestore may be referenced by
complete pathname, or by an incomplete pathname.
Every virtual filestore has a root object. The root is the
In the latter case, the responder resolves the
only object in the filestore that has no parent. This
incomplete pathname to a complete pathname using
root is either a file or a file-directory. It cannot be a
the current name prefix. The file protocol is designed
reference.
In the case where it is a file, that file will be
such that the responder need not reveal the current
the only object within that filestore.
name prefix to the initiator, should it be desirable to
The relationship of parenthood results in a hierarchical
conceal the filestore structure above this file-directory
model of the filestore, where the root node is
for security or other reasons.
represented by the filestore root object, intermediate
5a.3.2 Resolving a pathname
nodes are represented by file-directories maintaining
at least one parenthood relationship, and leaf nodes
A complete pathname is resolved to an object by a
are represented by files, references, and file- series of steps using the object names of the
directories maintaining no parenthood relationships. pathname to locate the intermediate objects along the
path in turn.
References may be used for convenience of access in
special situations, or for special security needs. Initially, the root node is located.
References provide a simple means of allowing an
For each step, while object names of the pathname
object to appear in more than one place in the filestore
remain to be resolved:
hierarchy without having to duplicate the object, or
worry a) if the object located is a reference, and the
about maintaining consistency between
duplicate objects. In normal use a user will not filestore user has passthrough access to this
observe any difference in behavior whether an object reference, then the object which it references is
is accessed via parenthood or reference. located (if the user does not have passthrough
access to this reference, or if the referenced
5a.3 Name resolution
object is not found, an error is reported);
An object is identified within the virtual filestore by a
b) if the object located is a file-directory, and the
pathname. A pathname is comprised of a series of
filestore user has passthrough access to this
object names.
Each object name in the series
file-directory, then the child object named by the
identifies the next child object in the virtual filestore.
next object name of the pathname is located (if
The last object name in the series identifies the target
the user does not have passthrough access to
object. The root object in a filestore is identified by a
this directory, or the next object name does not
pathname comprised of zero object names. The exact
correspond to any child of this directory, an error
algorithm is described in 5a.3.2.
is reported);
5a.3.1 The current name prefix
c) if the object located is a file, then an error is
When the pathname of an object begins its series of reported.
object names at the root of the filestore, it is called a
If the object located when all object names of the
complete pathname. Otherwise, to uniquely identify
pathname have been exhausted is a reference, then
an object within the virtual filestore, the incomplete
the final action taken depends on the operation being
pathname must be resolved to a complete pathname.
performed:
This is done with the current name prefix activity
attribute. The current name prefix is assigned to the d) if the operation is specific to reference objects,
association by the responder. The current name prefix then the operation is performed on the reference
is a complete pathname of a file-directory object. The object located;
actual mechanisms for this assignment are outside the
e) if the operation is not specific to reference
scope of FTAM, but possible uses could be for
objects, then the object to which the reference
providing default file-directories to users, protecting
refers is located, and the operation is performed
filestore users from potential filestore organizational
on the referenced object.
changes, or for enhanced security control.
5a.4 Object type checking
An incomplete pathname is resolved to a complete
If the object located when a pathname is resolved is
pathname by prepending the series of object names
within the current name prefix to the incomplete not of the type required for the operation to be
pathname. performed then an error is reported.
---------------------- Page: 5 ----------------------
IS0 8571.2:1988/Amd.l:1992 (E)
- directory
0
0 - reference
- - parenthood
e - linkage
Figure la - An example tree structure of a VFS
5a.5 Example GJKD
c)
Thus for file selection, the filestore in this example
Figure la shows an example of a filestore containing
appears as if duplications of data took place as in
references.
figure 1 b.
The file F has primary pathname E,F. However, it may
NOTES
also be accessed by the following names involving
references:
1) In normal use, except when explicit manipulation of the
reference object is carried out, a user will not observe
a) AD
any difference in behaviour whether an object is
b) WV=
accessed via parenthood or reference.
D
COPY
of F
COPY COPY D
COPY
of B of c
of F
\ f .
Figure 1 b - An example of the apparent structure of a VFS
---------------------- Page: 6 ----------------------
IS0 857%2:1988/Amd.l:1992 (E)
2) References may be used for convenience of access in generalized selection group activity attribute. Inclusion
special situations. References may have, in conjunction
in this group is based on the attribute assertions
with the path access control attribute, applications to
provided by the initiator.
Access permission by the
security and secure views of the filestore structure.
initiator to the files based on requested actions and
access authorization provided by the initiator is
(amend title of clause 6, page 4)
implicitly an assertion in identifying the group of
pathnames.
6 Object selection
NOTE -The generalized file selection mechanism does not
(amend 1st paragraph, page 4)
imply formal selection of the objects identified by
From outside the filestore, selection of an object is
pathname within the generalized selection group. It merely
always made using the pathname of the object. Even collects the pathnames for later use in other operations.
in the case of generalized selection services, the
Within the FTAM regime, multiple sequential select
actual selection of a single object from within the group
regimes can be established. These sequential select
of file objects maintained in the generalized selection
regimes are created either by selecting another
group activity attribute is made by implicit (i.e., internal
pathname in the generalized selection group, or by the
to the responder controlling the filestore) reference to
simple object selection mechanism, described above.
the pathname of the object. The reference to an
object is within the context of a particular filestore
Selecting another object in the generalized selection
identified by the application entity title. The application
group operates by requesting the responder to choose
entity title refers to the location of file storage, and is
a previously unselected pathname from the pathname
known to the file service users, but lies outside the
group, and attempting to select it. If it cannot be
scope of FTAM. The pathname of an object is defined selected (for example, it has been renamed or deleted
in clause 13.19. since it became a member of the group, or some
access control attributes controlling access to the
(insert after 1st paragraph, page 4)
object have been changed to exclude the initiator),
6.1 Methods of object selection then that pathname is removed from the pathname
group, a new previously unselected pathname is
Two methods of object selection are provided.
chosen, and the responder tries again. The current
6.1 .I Simple object selection pathname activity attribute is the pathname chosen.
No status codes are provided to the initiator to identify
(amend 2nd paragraph of clause 6, page 4)
this condition. A pathname is considered previously
Simple object selection takes place in two stages.
unselected until it is chosen by the responder during a
First, an FTAM regime is initialized with the application
select another action. Selecting an object explicitly by
entity handling the virtual filestore, and then
pathname does not affect it’s status as previously
information is given to this entity to identify the object
selected or not within the pathname group.
unambiguously from among all the objects in the
The initiator deselects an object, which was selected
filestore. This information is the pathname of the
in this manner, by deselecting or deleting the file or its
object. The current pathname activity attribute is set to
reference. The initiator is notified that no more
the pathname used to identify the selected object.
unselected pathnames exist in the group through a last
(replace 3rd paragraph of clause 6, page 4)
member indicator. If additional pathnames exist within
the group, but upon attempting to select the next one,
6.1.2 Generalized object selection
none are found that can be selected by this initiator,
The second form of object selection works only with (for example, a concurrency control lock is now in
file objects and references to file objects. It is the place), then an error is returned.
generalized selection mechanism. First, an FTAM
If, after either of these notifications, another request to
regime is initialized with the application entity handling
select another object is received from the initiator, the
the virtual filestore. Assertions regarding the file
responder then considers ail remaining pathnames in
objects’ attributes are provided by the initiator to the
the group as previously unselected, and begins again.
This group of complete pathnames is
responder.
If no pathnames remain in the list, a permanent error is
created and maintained by the responder in the
returned. No access guarantees are made regarding
the objects listed in the generalized selection group.
---------------------- Page: 7 ----------------------
IS0 8571-2:1988/Amd.l:1992 (E)
referenced object’s attributes match the assertions.
Pathnames may be removed from the group by the
responder if the responder determines that the object
(add after clause 7, page 7)
cannot be selected by the initiator. The initiator will not
be notified of any deletions from the group. It is
7a Actions on objects
possible that, because of references, the same file
The virtual filestore defines actions which manipulate
object will appear in the group multiple times, under
the objects within the filestore. The definition of the
different pathnames.
individual actions (see section two) states the objects
All generalized actions are considered to be specific to
to which actions apply, and the effects on those
a file object. Any references to file objects that may be
objects. Some actions also establish filestore state,
included in the generalized selection group are treated
such as the current name prefix, or generalized
transparently, so that users are not necessarily aware
selection group.
that they are dealing with a reference.
The actions are invoked by service primitives. Their
6.2 Selection of references
semantics are defined in conjunction with the filestore
management primitives defined in IS0 8571-3.
After selecting or creating a reference object, actions
appropriate to a reference object and actions
Use of each action is subject to access control by the
appropriate to the type of object referenced are
responder (see 12.16).
allowed (see 5a.3.2). Actions specific to a reference
9.1 Attribute scope
object operate on the selected reference object and
its attributes. Actions not specific to reference objects
(amend 1st paragraph, page 8)
operate on the referenced object and its attributes,
Two classes of attributes are defined:
with the exception of the object name attribute; in
this case, the referenced object “inherits” the object
a) object attributes; each object is described by
name attribute of the reference object for this specific
one set of object attribute values. The scope of
association for the duration of the select regime. The
the object attributes is the virtual filestore, and if
current pathname activity attribute is set from the
an object attribute value is changed by the
pathname used to identify the reference object.
actions of one initiator, the new value is seen by
any other initiators subsequently reading that
A change attribute action not specific to a reference
attribute. Some attributes are specific to the
object results in changes to the referenced object’s
type of object.
attributes, with the exception of the object name
attribute; in this case, the object name (and possibly
b) activity attributes; each activity takes place
the primary pathname) of the reference object is
within an FTAM regime and is described by one
changed.
set of activity attribute values. The scope of the
activity attributes is at most the FTAM regime,
Actions specific to reference objects are:
and a distinct and independent set of activity
a) F-LINK
attribute values is bound to each FTAM regime.
There are two distinct subdivisions of the activity
b) F-UNLINK
attributes.
c) F-READ-LINK-ATTRIB
1) The active attributes are in one to one
cl) F-CHANGE-LINK-AT-T-RIB
correspondence with the object attributes.
Actions involving attribute value assertion lists may
NOTE - In most cases the mapping is trivial,
operate directly on references, depending on the
since many file attributes are fixed at object
settings of the object type attribute value assertions, if creation time. However several of the active
attributes such as active contents type and active
any.
legal qualifications have distinct values which
When invoking an attribute value assertion list, the
are subsets of the object attribute values.
reference object’s attributes and the referenced
2) The current attributes concern the initiator
object’s attributes (with the inherited object name
and, are in general derived from the
attribute) are considered independently. The
parameters on the protocol exchanges.
reference object successfully matches the attribute
value assertion list if either of the reference object’s or
6
---------------------- Page: 8 ----------------------
IS0 857%2:1988/Amd.l:1992 (E)
pathnames of objects within the virtual filestore.
NOTE - The current attributes are not exactly
equivalent to static object attributes, but in some
An object pathname is described by an attribute value
cases are closely related. For example the
assertion list if all of the following are true:
current access passwords must be members of
the access passwords term in the access control
a) the initiator has read-attribute access to the
attribute.
object via that pathname;
(add after clause 9.4, page 9)
b) the initiator has read access to each file-
directory specified implicitly in the pathname
9.5 Extension attribute sets
pattern (see the note in 9a.1.2);
The file protocol provides a mechanism for access to
c) the initiator has passthrough access to each file-
object attribute sets which are defined externally to this
directory specified implicitly in the pathname
standard. This is done through extension attribute
pattern;
sets. An extension attribute set consists of an object
identifier to identify the attribute set definition, and
d) there exists at least one attribute value assertion
some number of attributes belonging to the identified
sublist in the attribute value assertion list for
attribute set. Each attribute is identified by it’s own
which every attribute value assertion within it
Object Identifier, and maintains a value specific to that
has the value ‘true’ for the object identified by
attribute.
that pathname.
If the initiator sends or requests the value of attribute
When performing actions on objects using attribute
sets not understood by the responder, the responder
descriptions to identify the set of objects, the initiator
merely ignores those attribute sets it does not
provides an attribute value assertion list to describe
understand, completing the action as though they had
the desired objects.
not been present.
The responder then creates a list of pathnames based
The responder must never send information about an
on the above criteria. The objects in this list of
attribute set not specifically requested by the initiator.
pathnames may then be operated upon singly, or as a
group.
Requesting or recognizing an attribute extension set
implies support for all attributes defined within the at-
9a.l Assertion types and components
tribute extension set, and their mechanics.
9a.l .l Relations for GraphicStrIngs
9a Attribute value assertion lists
Assertions regarding GraphicStrings are made in
terms of the logical relation “equality” in comparison to
The file protocol provides a means for identifying a set
string patterns. A string pattern consists of a
of object pathnames based on the attributes of the
sequence of substring patterns. A substring pattern
objects they identify. This mechanism is by attribute
can be any of three types:
value assertion list.
a) a specific sequence of characters;
An attribute value assertion consists of an
identification of an attribute, a target attribute value,
b) a specification for an exact number of characters
and a relationship. An attribute value assertion is true
(those characters which are unimportant);
for a specified object pathname if, for the object
c) a specification for zero or more characters.
identified by the pathname,
A GraphicString is equal to a string pattern if
a) the identified attribute exists for this object type,
and
1) every character in the GraphicString can be
sequentially matched with a character in a
b) the identified attribute for that object has the
pattern of type ‘a’, a position in a substring
specified relationship to the supplied target
pattern of type ‘b’, or a substring pattern of type
attribute value.
‘c’ (pattern types correspond to the numbering of
An attribute value assertion list consists of a set of
the list, above);
attribute value assertion sublists, each sublist
2) there are no characters in any string pattern of
consisting of a set of attribute value assertions. An
type ‘a’, or positions within string pattern type ‘b’
attribute value assertion list describes a subset of all
which do not have a corresponding character
from the GraphicString.
---------------------- Page: 9 ----------------------
IS0 8571-2:1988/Amd.l:1992 (E)
Table la - Bitstring and bitstring pattern relationships
Significance Value of
Meaning
assertion
I I I I
Not significant bit is not significant for matching
any
Significant 0 bit is significant and matches 0
Significant 1 bit is significant and matches 1
9a.l.2 Relations for Pathnames 9a.l.3 Relations for dates and times
Assertions regarding Pathnames are made in terms of
Assertions regarding dates and times can be made in
the logical relation “equality” in comparison to terms of
pathname patterns. Pathname patterns can be either
a) “less than” (i.e. before, or older than);
complete pathname patterns, specifying pathname
searches are to be made from the filestore root; or b) “greater than” (i.e. after, or younger than); or
incomplete pathnames, specifying pathname searches
“equality” (i.e. concurrent, or same age).
C)
are to be made from the file-directory identified by the
current name prefix. Assertions are evaluated according to both the
precision given and the precision available on the local
Either pathname pattern consists of a sequence of
system. .
component patterns. A component pattern can take
any of two forms: 9a.l.4 Relations for integers
a) a string pattern; Assertions regarding integers can be made in terms of
the logical relations
b) a specification for zero or more object names.
“less than”,
a)
A Pathname is equal to a pathname pattern if
“greater than”, or
b)
1) every object name in the Pathname can be
sequentially matched with a string pattern in a “equality”,
4
component pattern of type ‘a’, or a component
Where all are taken with their standard mathematical
pattern of type ‘b’ (pattern types correspond to
meanings,
the numbering of the list, above);
9a.l.5 Relations for bitstrings
2) there are no component patterns of type ‘a’
which do not have a corresponding object name
Assertions regarding bitstrings can be made in terms
from the Pathname.
of “equality” with a pattern. A bitstring pattern consists
of a significance mask and a value assertion. Matches
NOTES
against bitstring patterns are done on significant bits
1) An object name is said to be “explicit” if the component
as shown in Table la.
pattern is of type “a”, and that string pattern consists of
A bitstring is equal to a pattern if each significant bit in
a single substring pattern of type “a” (see 9a.1.1).
the bitstring matches the corresponding assertion
Otherwise, the ob
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.