home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / v21 / 174 < prev    next >
Internet Message Format  |  1990-12-05  |  3KB
  1. From jsq@cs.utexas.edu  Wed Oct  3 11:08:06 1990
  2. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3.     id AA14297; Wed, 3 Oct 90 11:08:06 -0400
  4. Posted-Date: 3 Oct 90 15:46:12 GMT
  5. Received: by cs.utexas.edu (5.64/1.76) 
  6. From: jason@cnd.hp.com (Jason Zions)
  7. Newsgroups: comp.std.unix
  8. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  9. Message-Id: <13142@cs.utexas.edu>
  10. Sender: jsq@cs.utexas.edu
  11. Organization: Hewlett Packard, Information Networks Group
  12. Subject-References: <13132@cs.utexas.edu> <13135@cs.utexas.edu>
  13. X-Submissions: std-unix@uunet.uu.net
  14. Date: 3 Oct 90 15:46:12 GMT
  15. Reply-To: std-unix@uunet.uu.net
  16. To: std-unix@uunet.uu.net
  17.  
  18. Submitted-by: jason@cnd.hp.com (Jason Zions)
  19.  
  20. Dominic Dunlop says:
  21.  
  22. > I dare say that, as more types of object appear in filename space (and
  23. > I, for one, should like to see them do so), the question of determining
  24. > uniqueness will become knottier.  Suppose, for example, that one used
  25. > filenames as handles for virtual circuits across a wide-area network.
  26. > Conceivably, the number of such circuits could be sufficiently large
  27. > that it will become difficult o shoe-horn a unique identifier into the
  28. > existing stat structure fields.  A problem for the future?
  29.  
  30. Actually, a problem for today. P1003.8 has to cope with the fact that a
  31. local file for major 0, minor 0x010100, inode 1234 is *different* from a
  32. file on some remote machine with the same (major,minor,inode) triplet. But
  33. adding a new field or fields to the stat structure isn't gonna work;
  34. expanding that structure will cause many implementations to shatter (i.e.
  35. break spectacularly). Just cobbling up a major number for some random
  36. remotely-mounted filesystem is unsatisfactory, unless the cobble is
  37. persistant over umount/mount operations. (An application starts to run;
  38. opens file1 on remsys, gets (maj,min,ino). Network goes down, comes up;
  39. system remounts remsys. App opens file2 on remsys. That major number had
  40. better be the same for remsys!)
  41.  
  42. What's needed is a simple routine which can be called to determine if two
  43. handles point to the same object. It would be nice if there was a routine
  44. which took as arguments a file handle and a path name and returned true iff
  45. the path referred to the same file. This routine would be guaranteed by the
  46. implementor to work for any file-system resident object provided for; e.g.
  47. an SVR4 implementation would have to be able to tell if a file opened via
  48. RFS referred to the same underlying file as one opened under NFS.
  49.  
  50. I don't know if that's sufficient, though; application programmers may be
  51. using the stat info for other purposes, and a remote_addr field might be a
  52. good idea. Once P1003.12 decides on a representation for an arbitrary
  53. network address, which might be considerably larger than an IP address.
  54.  
  55. Jason Zions
  56.  
  57. Volume-Number: Volume 21, Number 174
  58.  
  59.