Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.21/text0166.txt

Text File | 1990-10-26 | 5.4 KB | 101 lines

Submitted-by: [e-mail] (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