I promised at the end of the last chapter that I'd tell you how we use the extra integer value we store in the open file table. The story is that it indicates the machine on which the file is stored. If the value is zero, it is the local machine and standard THEOS I/O calls can be made. If not, we have secret and magic ways of figuring out where the file really is.

How do we identify a file that is on another machine? There are two different ways we do it. First the ever-present "extra" argument on the system call that does the open could force us to go to a specific machine. If the argument is just set to the "network-aware" value, our open routine takes a harder-than-usual look at the file name; if it contains a "!" character, we treat this as a signal that the file is on another machine. The path "abc.data:A!test" means we want to open the file "abc.data" which is on drive "A" of machine "test". Machine "test" could be the local machine or a remote machine; we can figure this out because we know who we are.

If the file is on a different machine, we have done about all we can do with native THEOS routines. Now we have to do some work. This is where the term "call deflection" comes in; instead of sending the call to THEOS for normal processing, we deflect the call to be handled by a server running on the other machine. It doesn't matter whether the other machine is running THEOS, Unix, or (ugh) NT; we just send it a description of what we need done, in some agreed-upon format, and it does the work. There is nothing especially difficult about this; the server on the other machine is just a program. As we'll see soon, there are several different "flavors" of servers.