jason@cnd.hp.com (Jason Zions) (10/02/90)
Submitted-by: jason@cnd.hp.com (Jason Zions) For 1003.8 Subset TFA, it is (in my understanding) the working group's intent to provide interface hooks to permit an application to be written portably and in such a fashion as to work correctly over *any* file sharing mechanism providing semantics at least as powerful as those required by what we're calling "Core TFA". The Core is weaker in semantics than NFS, certainly; it is roughly equivalent in power to FTAM using a very restricted set of FTAM File Types (by design!); it can be made to fit on top of the DOS filesystem. Common practice is to simply hack and tweak one's implementation to fit over this whole set of weaker filesystems. Common practice is not to warn programmers that files accessed over some network file sharing mechanism might behave *differently* from files accessed locally. Common practice for most non-POSIX filesystems is to use obscure or proprietary interfaces for controlling those interfaces, when control interfaces are provided at all. We expect to tie into 1003.1 and 1003.4 mechanisms to permit applications to be written to use standard interfaces to control things. Use pathconf() to tell if a particular file access semantic from 1003.1 is available. Add a new interface giving an application control over whether it can access files over mechanisms not supporting Full TFA. We expect to *clearly* delineate in the Subset TFA standard *exactly* what semantics some interface must provide if it claims to support a particular semantic feature. An application can say "If I open and unlink this file, will I retain access in all circumstances until I close it?" and get a meaningful answer. We looked at the gap between Full TFA (i.e. 1003.1) and Subset TFA (based on FTAM) and broke it down into a set of logically-related behaviors. We've called these sets "functional blocks". Many of these functional blocks are tied into constraints in 1003.1; if a mechanism does not claim to support one of those functional blocks, the meaning is that some constraint within 1003.1 has been relaxed under this mechanism. The list of functional blocks we're currently looking at can be found in 1003.8 D3, available from the usual source. The programming model for Subset TFA is based on inquiry about guarantees. On a 1003.8-compliant system, no application is permitted to perform operations on files not supporting full 1003.1 semantics *unless and until* the application *specifically* authorizes such subset behavior. That authorization can be granted process-wide or on a file-by-file basis. Once subset semantics are authorized, the implementation permits access to any file whose access mechanism supports *at least* Core Subset semantics. The application is _a_priori_ guaranteed only those Core semantics. For a given file, the application can inquire about what other semantics above and beyond Core semantics are guaranteed by the mechanism used to access the file. If an application doesn't like the semantics available for a given file, it knows up front; it can bail out, use workarounds, whatever. Example: An unmodified 1003.1-compliant application, running on a system providing the 1003.8 interface, will *never* be permitted to operate on a file whose access mechanism fails to provde full 1003.1 semantics. (Operations will fail with a new error; I think we're looking at using EOPNOTSUPP.) (You realize, of course, that *something* ceases to conform whenever a strictly-conforming POSIX application opens an NFS file on a POSIX system; that application ceases to receive semantics guaranteed by 1003.1. Who's at fault: the system, for permitting the application to open the file, or the application, for not making sure it gets what it thought it got?) Example: A 1003.1-compliant application, which has had a single call added to it to authorize subset-semantic behavior but has had no other modifications, will be permitted to operate on any file whose access mechanism provides at least Core Subset semantics. (Many programs will be written just this way. We're wrestling with some issues here: Should process-wide authorization be inheritable over fork()? We think yes. Over exec()? We think not. Should there be an external authorization mechanism not requiring code changes and recompiles? We don't know.) Example: An application might need only the ability to seek to an arbitrary location in a file and write at that point. It would first open the file, authorizing subset semantics. It might then inquire (using pathconf()) if the mechanism used to access the file supported seeks. If so, it would simply seek, write, and close. Otherwise, it might open a temporary file in the same directory as the source, copy the contents of the file up to the seek point, then write the data it wanted to, then write the rest of the source; finally, destroy the source file and move the copy on top of it. Behavior is the same, but performance is lower in the second case; nonetheless, the application can be written *portably* to behave in the most efficient manner possible. (Note that FTAM Type 1 files do not permit arbitrary seeks. Note also that most Unix####POSIX filters do not need seeks.) That's what we're about. Please remember the usual disclaimer; although I chair 1003.8, my word is not law; I may have misunderstood the group's direction, or the technical content of the draft. I am not speaking on behalf of the entire working group. Jason Zions Chair, 1003.8 POSIX Transparent File Access Volume-Number: Volume 21, Number 166