The low cost of computer hardware has made the personal computer and the workstation an integral part of the workplace. As a result, the need for communications between these systems has increased dramatically. Not only has the quantitative need increased, but the nature of that need has changed. Previously, the ability to log into remote systems and to transfer files was sufficient for users of personal computers and workstations. Now it is becoming the norm to access the services available through a communication network in a manner consistent with accessing the services of the local system.
Such ``transparent'' services include electronic mail and the use of remote devices, e.g., disks, tapes, and printers, as though they were physically local. Previously, access to electronic mail usually required the user to log into a remote large system in order to send and receive mail. Now, it is common for a user to run software on the local system which transparently accesses a remote mail server. The user's mail is actually sent and received by the mail server. However, the user perceives that the mail is sent and received by the local system which, in many cases, is too small to act as a mail server.
Previously, access to remote devices, such as disks and printers, was usually provided only by first transferring files to the system where the device was physically connected. Now, access to remote devices is provided as though the devices were connected locally. In the case of accessing remote file systems, such access is referred to as ``transparent file access.'' A user need not know whether a device is local or remote.
Application programs are the means by which services are provided to users. Application programs that make use of transparent file access require an application programming interface and the support of network protocols. Network protocols are required in order to accomplish the communication between systems. This communication is necessary so that remote file systems appear local. The application program need not be directly concerned with network protocols. The network protocols are provided as a result of the application program's use of the application programming interface. The application programming interface reflects the semantics of the file system being used by the application program.
For example, the Network File System
(NFS)
developed by Sun Microsystems is
a protocol which is layered above the TCP/IP (Transmission Control
Protocol/Internet) protocol suite. The application programming
interface for NFS is the Unix application programming interface
which provides most of the the file system semantics of Unix. Another example
is NETBIOS which provides the DOS Redirector network access
using the SMB protocol. Application programs use the DOS
application programming interface which provides the file system
semantics of DOS over a network by means of the DOS Redirector.
Both standard network protocols and a standard application programming interface are necessary for transparent file access in order to ensure interoperability between systems and portability of applications. The transparent file access environment can be described by means of a client/server model (see cover illustration). A client, such as the personal computer in the cover illustration, accesses both local and remote files. Local files, such as those on C: in the cover illustration, are resident on a disk which is directly connected to the client. Remote files, such as those on D: in the cover illustration, are physically located on a server which is connected to a network as is the client. The application program need not be aware of whether a file is local or remote.
Regardless of the physical location of a file, the client accesses the file according to the file system semantics of the client's operating system. The file system semantics of the client operating system may differ from the file system semantics of the server. Moreover, the file system semantics of two clients accessing the same server may be different from each other and different from the server. It is a function of the client implementation and the server implementation as to who, i.e., the client, the server, or both, has the responsibility for guaranteeing the client's file system semantics when server files are accessed.
For example, as illustrated on the cover, a personal computer using DOS and a workstation using Unix may be accessing files from a VAX VMS server. The personal computer, the workstation, and the VAX must be using the same network protocols in order to interoperate. Consider application programs running on the personal computer, the workstation, and the VAX. The application program on the personal computer must access files using the DOS file system semantics; the application program on the workstation must access files using Unix file system semantics; and the application program on the VAX must access files using VMS file system semantics. Such an environment is not conducive to portable applications. A standard application programming interface is necessary in order for application programs to be portable among clients and servers in environments such as these.
Under development in the IEEE Transparent File Access (TFA) Working Group, 1003.8 is a revision to IEEE 1003.1-1990 (ISO/IEC 9945-1:1990). The TFA Working Group is part of the IEEE POSIX Standards Committee (IEEE P1003). This revision provides a file system access specification which would permit access to the widest possible range of file systems which can resemble the file system of IEEE 1003.1-1990. The Transparent File Access Standard of IEEE 1003.8 provides the means for an application to simultaneously manipulate files whose access characteristics differ because they belong to file systems with different file system semantics. In addition, the specification for the first time provides a standard way of characterizing and profiling the capabilities of file systems.
This report provides the background needed to understand the TFA Standard. Because the development of the TFA Standard is ongoing as this report is published, this report does not reference any Draft of the TFA Standard and only presents the significant issues which are motivating the development of the TFA Standard. The report goes beyond the rationale of the TFA Standard, which summarizes why certain choices were made by the TFA Working Group in their development of the TFA Standard. This report presents an in-depth description of the major issues on which the choices were based.
The report assumes that the reader has some knowledge of Unix. Since the issues described are common to most Unix implementations, the issues are presented in such a manner as to be understandable to a reader who is familiar with some Unix implementation. Although all issues presented are issues for IEEE 1003.1-1990, familiarity with IEEE 1003.1-1990 is not required. Where IEEE 1003.1-1990 differs from a traditional Unix implementation with regard to an issue, that difference is mentioned. It is not intended that the description of an issue be a tutorial on the specific Unix functionality involved in the issue. Only those aspects of Unix functionality which directly impact the issue are highlighted.
Some issues are illustrated with examples and demonstrations using the NFS implementation of SunOS 4.1 from Sun Microsystems on both the client and the server. In this report, the term NFS always refers to the NFS Version 2 Protocol. Within the text which describes each demonstration, the term NFS refers to the client and server implementation of the NFS Version 2 Protocol in SunOS 4.1. The results of the demonstrations may be different if other NFS client or server implementations are used. NFS is the most widely used implementation for accessing remote files in a network environment. For those issues chosen for demonstration, the choice was based on the importance and complexity of the issue, and how amenable the issue was to an easily understood and reproducible demonstration.
This report is intended for managers, programmers, and users in government and industry to assist in their understanding, evaluation, management, and use of the TFA Standard and systems which provide access to remote file systems. The main body of the report discusses the issues which arose during the development of the TFA Standard. TFA issues may be characterized as belonging to one of the following categories:
These are issues which arise when trying to implement some aspects of IEEE 1003.1-1990 in an environment for which it was not designed, e.g., a network environment. IEEE 1003.1-1990 applies only to local file systems. Some capabilities cannot be implemented within the context of IEEE 1003.1-1990 in a network environment.
These are issues which also arise when applying IEEE 1003.1-1990 to an environment for which it was not specifically developed. However, instead of relating specifically to capabilities which cannot be implemented within the context of IEEE 1003.1-1990, these issues concern capabilities whose implementation may result in an unacceptable level of performance.
These are issues which arise because of the need for the TFA Standard to be applicable to specific existing or emerging file systems or network protocols.
These are issues which do not clearly fit in any of the other categories or which have implications for all of the other categories.
While some issues may have implications for more
than one category, each issue is listed only within the
category where it has the most significance.
Chapter 6 summarizes the results of this report.
Appendix 
contains references and related reading.
Appendix
contains listings of the programs used in the demonstrations.
Assistance in the debugging of these program listings by Dan
Nielsen and Craig Sparkman is much appreciated.