2.8 File Name Management

File names present a host of problems for a program like FunnelWeb. First, FunnelWeb can generate so many different kinds of files that conventions must be adopted to prevent their names from colliding. Second, the constraints on file names, and even the structure of file names themselves varies considerably from machine to machine. These two problems have combined to result in the sophisticated and rather complicated way in which FunnelWeb handles filenames.

To summarize, the three problems are:

1. What filename extensions should be chosen for various kinds of file?
2. What filename inheritance should take place?
3. How should FunnelWeb cope with the variations in filename structure between platforms?

These problems are addressed in the following sections.

Filename Extensions

FunnelWeb is capable of reading and writing a variety of different kinds of files. In particular, FunnelWeb must often operate in an environment where the same information is stored in many forms (e.g. prog.fw, prog.c, proc.exe). File extensions are an essential tool in managing this situation. The default filename extensions chosen for FunnelWeb are:

FunnelWeb     : .fw
Product       : None
Documentation : .tex or .html
Listing       : .lis
Journal       : .jrn

Lowercase will be used in systems that are case sensitive.

Filename Inheritance

Inheritance in filenames refers to how input and output files inherit parts of their name from other filenames and their environment. For example if the command

   fw sloth +J +L +T

were issued, you would expect to see output files sloth.jrn, sloth.lis, and sloth.tex. The output file names have inherited the "sloth" part of the argument. In fact, FunnelWeb implements a comprehensive filename inheritance scheme, which is shown in the following table. Each filename is built up by starting at the top of its column in the table and working down the column, inheriting filename fields (directory, name, extension) that are absent at that point.

The following notes explain the table.

1. Level 1 has the highest priority because it is a direct specification by the user.
2. Level 2 comes next because this is also a direct specification from the user on the command line.
3. Level 3 provides the default file extensions. Product files do not inherit an extension.
4. Level 5 is built into most operating systems' file specification systems. If you specify file "x.y", it is taken to mean on the default disk in the default directory.
5. Level 4 looks straightforward, but secretly conceals a difficult design decision. By the time we get down to this level of inheritance, we know for sure that the filename has already picked up a file extension. So all that is left to inherit is the path and the filename proper. Obviously we have to inherit the filename proper (e.g. sloth in sloth.tex), but should we inherit the input file path? If we do inherit the input file path, files will be placed in the same directory as the input file. If we don't inherit the input file path, files will be placed in the current directory. The choice made is to send all the logging type files into the same directory as the input file. This means, for example, that sloth.lis and sloth.tex will generally land in the same directory as sloth.fw. However, product files are sent to the default directory (if not earlier specified), as this is where the action is. In normal use, the main output of FunnelWeb will be product files, and so the user will expect them to appear in the current directory by default.

Portable Structure of File Names

Another problem with file names is the variation of their structure between environments. Here are examples of some of the formats that prevail:

   UNIX   /device/dir1/dir2/name
   VMS    node::device:[dir1.dir2]name.ext;vn
   MSDOS  device:\dir1\dir2\name.ext
   MAC    device:dir1:dir2:name

The solution to dealing with these different formats is to classify them as non-portable and hide the functions that manipulate them in the machine-specific module of FunnelWeb. Luckily there are not many such functions.

The main problem is coping with file systems that do not explicitly support file extensions. With so many possible input and output files, FunnelWeb all but needs such extensions. Machines that do not support them pose difficult design decisions. If the user specifies "sloth" as an input file on such a non-extension-supporting system, should FunnelWeb look for sloth or sloth.fw? If the user specifies walrus as a listing file, should it generate walrus or walrus.lis?

Some possible solutions are:

1. Regard the filename sloth as having an empty extension. It will then default to sloth.fw.
2. Regard the filename sloth as having a blank but full extension. That is, it cannot be overwritten by inheritance, but it remains blank.
3. Provide an extra syntactic mechanism to allow the user to specify one or other of the two options above.

The solution adopted in FunnelWeb is the first option. Use of FunnelWeb results in lots of files lying around (e.g. sloth.lis) and it is hard to see how the user will cope with them all without some kind of naming discipline. If a naming discipline has to be used, it might as well be the FunnelWeb one.

Thus the names of all files read and written by FunnelWeb will have a file extension of from zero to three letters separated from the rest of the filename by a ".".

The only exception is product files, whose extension is left undefined. Product files need not contain a "." and a file extension.