8.8 Notes on File I/O

There are a number of observations that should be made in connection with the module(s) that handle I/O at this particular level (stream and/or file) in Modula-2.

1) As already noted, apart from ISO standard Modula-2, these I/O module names may vary from one implementation to another. Naturally, the names of the individual objects in them will vary also, but the ones given here should be fairly typical.

2) In creating and using names for the physical files situated on the disk, there is almost always a strict limitation on the number of characters that may appear in a name. Exclusive of a three of four letter suffix such as .TXT or .OBJ, a typical limit may be as low as eight to ten characters in some primitive operating systems. If more than this number of characters are specified, the system may generate an error, or it may truncate the identifier down to the limit and then try to open the file, perhaps without telling the user that it has done so. In most cases, this will probably be satisfactory, but care must be taken not to end up with the same first characters for what were supposed to be two different file names. In that case, when the second file is written to, all the data from the first one will be lost. This system limitation, whatever it is, will probably apply to the names of all separately compiled modules, whether they are collected into a library or not.

3) There may well be several disk devices on line at the same time. These are usually distinguished by either a "device number" or by having a "volume name" of their own. In these cases, the file name could also have a "prefix" to identify the device. Here are a few examples from various systems:

"MYDISK:MYFILES.TEXT" denotes the text file named "MYFILES" on the disk whose name is "MYDISK".

"#5:NEWFILES" denotes the file "NEWFILES" on the device numbered 5.

"C:DATAFILE.TXT" denotes the device name "C:" (usually the hard disk) and the text file "DATAFILE". This particular designation assumes that any directory and subdirectory names that might be required have previously been set so that they are not needed in the file name.

"MYDISK/MYFILES/STUFF" (or with backslashes in some systems) denotes the main directory "MYDISK", the subdirectory "MYFILES" and the file "STUFF" within that subdirectory. In operating systems employing such designations, these are called "Pathnames"

Although these are from different operating systems, and no one of them would allow all these ways of locating a file, one can make a few general comments. Where volume names are employed, the system should be able to find the file regardless of which physical device contains the disk. If a number or letter to designate a device is employed, that device will be used, regardless of the volume name found there. If no prefix is supplied by the program, the system itself will look for the volume name or path name set as the prefix either by the system filer or when the disks were first started up.

Several other approaches to the use of volumes may be used, and in some systems there will be a module containing a collection of procedures for mounting, dismounting, and otherwise manipulating volumes as distinct from files.

4) Notice that in using the version's higher level procedures OpenInput and OpenOutput from the classical procedure InOut, one has to provide the default suffix ".TEXT" as the parameter. In that case, if the file could not be found, the system would add the suffix provided and try again. In using the lower level modules in this section one must specify the exact filename, including any necessary suffix. This is also the case in those systems that vary the use of OpenInput and OpenOutput to take filenames instead of default extensions to filenames.

5) Note too that on many systems physical file names are case-insensitive. That is, "MyProgram" (as a file name) would be equivalent to "MYPROGRAM" as far as the operating system is concerned.

6) When reading a "stream" or "text" in those systems that have this type, the fact of EOS (or EOT) becoming true does not necessarily imply that the end of the connected physical file was reached. This function can also return TRUE if the EOF character (where one is defined) was read (usually Control-C or Control-Z). Hopefully, this also corresponds to the physical end of the file, and it will in most cases, but a stray control character could prematurely terminate a file and cut off access to part of it.

8.8.1 Special Notes on the Macintosh Operating System

In addition to some of the other considerations, the Macintosh operating system has as an integral part of its operation the concept of a Creator and a Type as explicit file information. Applications store creator information with their files, so that when these files are opened from the finder, the creating application will be opened as well. In addition, each application may be capable of creating and opening one or more types of files, including ones normally used by other applications.

Creator and Type are both defined as ARRAY [0..3] OF CHAR, and must be provided whenever a file is created. Thus, the ISO modules SeqFile, StreamFile, and RndFile must pass this information to the operating system whenever they create a file. Since this facility is not included in the ISO modules themselves, some default type and creator must be maintained at a lower level. There should also be a means of changing this information. In the p1 compiler this is handled by importing from MacMisc using:

PROCEDURE SetTypeAndCreator (cid: ChanId; type, creator: OSType);
(* if "cid" identifies an open channel to a disk file, type and creator are set according to the parameters. Otherwise the exception "notAChannel"or "notAvailable" is raised.
*)

Note that here, the type and creator have to be set on a channel once it is opened. In the author's own implementation, this is done a little differently, using:

DEFINITION MODULE  MacFileTypes;

(* =========================================
  Definition and Implementation  1993
                by R. Sutcliffe
        Trinity Western University
7600 Glover Rd., Langley, BC Canada V3A 6H4
         e-mail: rsutc@twu.ca
    Last modification date 1993 10 20
=========================================== *)

(* The purpose of this module is to allow for standard creators and file types to be communicated from one module to another -- usually from a client program to some library module.  In this implementation, the intention is that the ISO device drivers will call the procedures here to determine what type and creator to use when connecting channels to files. *)

FROM Filer IMPORT
  NameType; (* an ARRAY 0..3 OF CHAR *)

(* Set and get file types *)

PROCEDURE SetSeqType (t : NameType);
PROCEDURE SeqType (): NameType;
  (* the default is "TEXT" *)

PROCEDURE SetStreamType (t : NameType);
PROCEDURE StreamType (): NameType;
  (* the default is "TEXT" *)

PROCEDURE SetRndType (t : NameType);
PROCEDURE RndType (): NameType;
  (* the default is "????" *)

PROCEDURE SetGenType (t : NameType);
PROCEDURE GenType (): NameType;
  (* the default is "????"  This one is for user programs or device drivers *)

(* Set and get creator types *)

PROCEDURE SetSeqCreator (t : NameType);
PROCEDURE SeqCreator (): NameType;
  (* the default is "????" *)

PROCEDURE SetStreamCreator (t : NameType);
PROCEDURE StreamCreator (): NameType;
  (* the default is "????" *)

PROCEDURE SetRndCreator (t : NameType);
PROCEDURE RndCreator (): NameType;
  (* the default is "????" *)

PROCEDURE SetGenCreator (t : NameType);
PROCEDURE GenCreator (): NameType;
  (* the default is "????"  This one is for user programs or device drivers *)

END MacFileTypes.

Here, there is a default type that is used all the time by each of the standard modules, but this default may be changed by the user for subsequently created files. However, to change the type or creator of an existing file requires lower level procedures.

Needless to say, this information is useless unless the programmer knows what strings to use. "MPS " (note the space after the 'S') is the creator of Macintosh Programming Workshop files, and "NISI" is the creator of Nisus word processing files. "TEXT" is the type of text files, and is already the default for both stream models. "????" is a generic creator/type marker.


Contents