Path: utzoo!attcan!uunet!ogicse!uwm.edu!wuarchive!cs.utexas.edu!jsq
From: domo@tsa.co.uk (Dominic Dunlop)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-ID: <13135@cs.utexas.edu>
Date: 3 Oct 90 09:27:45 GMT
References: <106697@uunet.UU.NET> <107020@uunet.UU.NET>
Sender: jsq@cs.utexas.edu
Reply-To: domo@tsa.co.uk
Organization: The Standard Answer Ltd.
Lines: 46
Approved: jsq@cs.utexas.edu (Moderator, John S. Quarterman)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: domo@tsa.co.uk (Dominic Dunlop)

In article <107020@uunet.UU.NET> donn@hpfcrn.fc.hp.com (Donn Terry) writes
cogently about file system and other name spaces.  I'm not going to add
significantly to what he said, merely embroider a little:

> One of the class of objects named in the namespace is ordinary files.
> The set of ordinary files is a collection of flat namespaces, where
> the names are (binary) numbers.  (Each mounted volume is an element
> of the collection, and each i-number is a filename.  The "real names"
> of files are the volume and i-number pair; that's how you tell if two
> files are identical, not by their names in the namespace, of which
> they may have zero or more.)  (The fact that the other object types
> also usually have i-numbers is an accident of implementation.)

I'd just like to add that the existing POSIX.1 standard does incorporate
the concept of ``a per-file system unique identifier for a file'',
although its ethnic origins have been disguised by calling it a ``file
serial number'' rather than an i-number.  The corresponding field in the
stat structure is, by no coincidence at all, st_ino.

Donn's point about the need to be able to determine whether two
``handles'' (whatever they may be) refer to the same object is a good
one.  It follows that, if new types of object are made accessible
through filename space, the information returned by stat() (or fstat())
should be sufficient uniquely to identify each distinct object.  Of
course, where the object is not a conventional file, life becomes more
complex than simply saying that each unique serial number/device id
combination refers to a unique object.  Although POSIX.1 is 
reticent on the topic because it is studiously avoiding the UNIX-ism of
major and minor device numbers, we all know that, faced with a device
file on a UN*X system, we should ignore the serial number, and use only
the device id in determining uniqueness.

I dare say that, as more types of object appear in filename space (and
I, for one, should like to see them do so), the question of determining
uniqueness will become knottier.  Suppose, for example, that one used
filenames as handles for virtual circuits across a wide-area network.
Conceivably, the number of such circuits could be sufficiently large
that it will become difficult o shoe-horn a unique identifier into the
existing stat structure fields.  A problem for the future?

-- 
Dominic Dunlop

Volume-Number: Volume 21, Number 172