Routing Requests to the FSDs

The FSDs provide the mapping from the file system disk format into the IFS interface functions. A redirector is an FSD that maps these functions on to a network rather than a local disk. The network redirector FSDs are vendor specific VxD's that interface to different back end file servers (i.e., Novell, Banyan, and Lanman to name a few). They provide the network specific support required to service the Win32 and INT 21h IFS manager requests. Since there is no file system built into the system, at least one FSD is required for file I/O. There is also no explicit design limit on the number of FSDs that can be loaded in the system at the same time. At this time, there is a limit of ten local and ten remote FSDs that can be loaded. This limit is not rigid and can be easily increased. FSDs do not use or rely on most of the DOS data structures.

The IFS/INT 21h Manager determines the correct FSD to call for each file I/O request using handles or path names. Handles are first created by the IFS Manager as a result of a request like "open file." Each handle corresponds to a specific FSD, and this relationship is kept in a system file handle structure. When a handle is passed back to the IFS Manager, it is used to locate the system file handle structure which identifies the FSD and the FSD specific handle for the request. When a pathname is passed in a call to the IFS Manager, the correct FSD is determined based on the driveletter or name. If this cannot be done, the FSDs are called in order until one of them accepts the call. There is no explicit ordering scheme to specify the order in which the FSDs are called. There is no explicit scheme for ordering the load order of FSDs at this time apart from the VxD device init order.

The following are a few different types of functions the IFS components will handle.

• Functions which enumerate an available resource. This type of function will check for the resource on all FSDs running on the system. Each FSD will be called in order. In this case the order does not really matter since each FSD will be called.
• Functions which search for a particular resource. This type of function will check each FSD in order until the resource is found. When the desired resource is found the search will stop. Any remaining FSDs will not be searched. If multiple FSDs contain a resource with the same name, the second one in the search order will not be found. It is up to the administrator of the system or network environment to avoid such conflicts.
• Functions which are associated with a specific FSD. This type of function will typically make an association with an FSD through a prior call such as an open. The IFS Manager components will keep local data structures where possible to allow these functions to be directly dispatched to the desired FSD.