home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / v21 / 166 < prev    next >
Internet Message Format  |  1990-12-05  |  6KB
  1. From jsq@cs.utexas.edu  Tue Oct  2 13:53:05 1990
  2. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3.     id AA24486; Tue, 2 Oct 90 13:53:05 -0400
  4. Posted-Date: 2 Oct 90 16:50:09 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: What's 1003.8 doing? (Was Re: make DOS a filesystem?)
  9. Message-Id: <13101@cs.utexas.edu>
  10. Sender: jsq@cs.utexas.edu
  11. Organization: Hewlett Packard, Information Networks Group
  12. X-Submissions: std-unix@uunet.uu.net
  13. Date: 2 Oct 90 16:50:09 GMT
  14. Reply-To: std-unix@uunet.uu.net
  15. To: std-unix@uunet.uu.net
  16.  
  17. Submitted-by: jason@cnd.hp.com (Jason Zions)
  18.  
  19. For 1003.8 Subset TFA, it is (in my understanding) the working group's
  20. intent to provide interface hooks to permit an application to be written
  21. portably and in such a fashion as to work correctly over *any* file sharing
  22. mechanism providing semantics at least as powerful as those required by
  23. what we're calling "Core TFA". The Core is weaker in semantics than NFS,
  24. certainly; it is roughly equivalent in power to FTAM using a very
  25. restricted set of FTAM File Types (by design!); it can be made to fit on
  26. top of the DOS filesystem.
  27.  
  28. Common practice is to simply hack and tweak one's implementation to fit
  29. over this whole set of weaker filesystems. Common practice is not to warn
  30. programmers that files accessed over some network file sharing mechanism
  31. might behave *differently* from files accessed locally. Common practice for
  32. most non-POSIX filesystems is to use obscure or proprietary interfaces for
  33. controlling those interfaces, when control interfaces are provided at all.
  34.  
  35. We expect to tie into 1003.1 and 1003.4 mechanisms to permit applications
  36. to be written to use standard interfaces to control things. Use pathconf()
  37. to tell if a particular file access semantic from 1003.1 is available. Add
  38. a new interface giving an application control over whether it can access
  39. files over mechanisms not supporting Full TFA.
  40.  
  41. We expect to *clearly* delineate in the Subset TFA standard *exactly* what
  42. semantics some interface must provide if it claims to support a particular
  43. semantic feature. An application can say "If I open and unlink this file,
  44. will I retain access in all circumstances until I close it?" and get a
  45. meaningful answer.
  46.  
  47. We looked at the gap between Full TFA (i.e. 1003.1) and Subset TFA (based
  48. on FTAM) and broke it down into a set of logically-related behaviors. We've
  49. called these sets "functional blocks". Many of these functional blocks are
  50. tied into constraints in 1003.1; if a mechanism does not claim to support
  51. one of those functional blocks, the meaning is that some constraint within
  52. 1003.1 has been relaxed under this mechanism. The list of functional blocks
  53. we're currently looking at can be found in 1003.8 D3, available from the
  54. usual source.
  55.  
  56. The programming model for Subset TFA is based on inquiry about guarantees.
  57. On a 1003.8-compliant system, no application is permitted to perform
  58. operations on files not supporting full 1003.1 semantics *unless and until*
  59. the application *specifically* authorizes such subset behavior. That
  60. authorization can be granted process-wide or on a file-by-file basis.
  61.  
  62. Once subset semantics are authorized, the implementation permits access to
  63. any file whose access mechanism supports *at least* Core Subset semantics.
  64. The application is _a_priori_ guaranteed only those Core semantics. For a
  65. given file, the application can inquire about what other semantics above
  66. and beyond Core semantics are guaranteed by the mechanism used to access
  67. the file. If an application doesn't like the semantics available  for a
  68. given file, it knows up front; it can bail out, use workarounds, whatever.
  69.  
  70. Example: An unmodified 1003.1-compliant application, running on a system
  71. providing the 1003.8 interface, will *never* be permitted to operate on a
  72. file whose access mechanism fails to provde full 1003.1 semantics.
  73. (Operations will fail with a new error; I think we're looking at using
  74. EOPNOTSUPP.)
  75.  
  76. (You realize, of course, that *something* ceases to conform whenever a
  77. strictly-conforming POSIX application opens an NFS file on a POSIX system;
  78. that application ceases to receive semantics guaranteed by 1003.1. Who's at
  79. fault: the system, for permitting the application to open the file, or the
  80. application, for not making sure it gets what it thought it got?)
  81.  
  82. Example: A 1003.1-compliant application, which has had a single call added
  83. to it to authorize subset-semantic behavior but has had no other
  84. modifications, will be permitted to operate on any file whose access
  85. mechanism provides at least Core Subset semantics.
  86.  
  87. (Many programs will be written just this way. We're wrestling with some
  88. issues here: Should process-wide authorization be inheritable over fork()?
  89. We think yes. Over exec()? We think not. Should there be an external
  90. authorization mechanism not requiring code changes and recompiles? We don't
  91. know.)
  92.  
  93. Example: An application might need only the ability to seek to an arbitrary
  94. location in a file and write at that point. It would first open the file,
  95. authorizing subset semantics. It might then inquire (using pathconf()) if
  96. the mechanism used to access the file supported seeks. If so, it would
  97. simply seek, write, and close.  Otherwise, it might open a temporary file
  98. in the same directory as the source, copy the contents of the file up to
  99. the seek point, then write the data it wanted to, then write the rest of
  100. the source; finally, destroy the source file and move the copy on top of
  101. it. Behavior is the same, but performance is lower in the second case;
  102. nonetheless, the application can be written *portably* to behave in the
  103. most efficient manner possible.  (Note that FTAM Type 1 files do not permit
  104. arbitrary seeks. Note also that most Unix####POSIX filters do not need
  105. seeks.)
  106.  
  107. That's what we're about. Please remember the usual disclaimer; although I
  108. chair 1003.8, my word is not law; I may have misunderstood the group's
  109. direction, or the technical content of the draft. I am not speaking on
  110. behalf of the entire working group.
  111.  
  112. Jason Zions
  113. Chair, 1003.8 POSIX Transparent File Access
  114.  
  115. Volume-Number: Volume 21, Number 166
  116.  
  117.