home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso / std_unix / v21 / 172 < prev    next >
Internet Message Format  |  1990-12-05  |  3KB
  1. From jsq@cs.utexas.edu  Wed Oct  3 08:53:15 1990
  2. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3.     id AA00821; Wed, 3 Oct 90 08:53:15 -0400
  4. Posted-Date: 3 Oct 90 09:27:45 GMT
  5. Received: by cs.utexas.edu (5.64/1.76) 
  6. From: domo@tsa.co.uk (Dominic Dunlop)
  7. Newsgroups: comp.std.unix
  8. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  9. Message-Id: <13135@cs.utexas.edu>
  10. References: <106697@uunet.UU.NET> <107020@uunet.UU.NET>
  11. Sender: jsq@cs.utexas.edu
  12. Reply-To: domo@tsa.co.uk
  13. Organization: The Standard Answer Ltd.
  14. X-Submissions: std-unix@uunet.uu.net
  15. Date: 3 Oct 90 09:27:45 GMT
  16. To: std-unix@uunet.uu.net
  17.  
  18. Submitted-by: domo@tsa.co.uk (Dominic Dunlop)
  19.  
  20. In article <107020@uunet.UU.NET> donn@hpfcrn.fc.hp.com (Donn Terry) writes
  21. cogently about file system and other name spaces.  I'm not going to add
  22. significantly to what he said, merely embroider a little:
  23.  
  24. > One of the class of objects named in the namespace is ordinary files.
  25. > The set of ordinary files is a collection of flat namespaces, where
  26. > the names are (binary) numbers.  (Each mounted volume is an element
  27. > of the collection, and each i-number is a filename.  The "real names"
  28. > of files are the volume and i-number pair; that's how you tell if two
  29. > files are identical, not by their names in the namespace, of which
  30. > they may have zero or more.)  (The fact that the other object types
  31. > also usually have i-numbers is an accident of implementation.)
  32.  
  33. I'd just like to add that the existing POSIX.1 standard does incorporate
  34. the concept of ``a per-file system unique identifier for a file'',
  35. although its ethnic origins have been disguised by calling it a ``file
  36. serial number'' rather than an i-number.  The corresponding field in the
  37. stat structure is, by no coincidence at all, st_ino.
  38.  
  39. Donn's point about the need to be able to determine whether two
  40. ``handles'' (whatever they may be) refer to the same object is a good
  41. one.  It follows that, if new types of object are made accessible
  42. through filename space, the information returned by stat() (or fstat())
  43. should be sufficient uniquely to identify each distinct object.  Of
  44. course, where the object is not a conventional file, life becomes more
  45. complex than simply saying that each unique serial number/device id
  46. combination refers to a unique object.  Although POSIX.1 is 
  47. reticent on the topic because it is studiously avoiding the UNIX-ism of
  48. major and minor device numbers, we all know that, faced with a device
  49. file on a UN*X system, we should ignore the serial number, and use only
  50. the device id in determining uniqueness.
  51.  
  52. I dare say that, as more types of object appear in filename space (and
  53. I, for one, should like to see them do so), the question of determining
  54. uniqueness will become knottier.  Suppose, for example, that one used
  55. filenames as handles for virtual circuits across a wide-area network.
  56. Conceivably, the number of such circuits could be sufficiently large
  57. that it will become difficult o shoe-horn a unique identifier into the
  58. existing stat structure fields.  A problem for the future?
  59.  
  60. -- 
  61. Dominic Dunlop
  62.  
  63. Volume-Number: Volume 21, Number 172
  64.  
  65.