This document describes the interaction between MultiFSs and host filing systems with respect to disc unique identification numbers.

Let's be honest, the only host filing system is FileCore, so, for brevity, I'll talk in terms of FileCore, rather than the generic host filing system. The system described is, however, not FileCore specific, so the description will be useful in general.

FileCore has the concept of a disc id number (disc unique identification number) which is used by FileCore to tell when a disc has changed, or is a different disc with the same id number. In order that FileCore's algorithm for matching a newly inserted disc with an old disc record to work FileCore has to be kept up to date with the latest value of a disc id. Also, there are times when FileCore has to make a request of a MultiFS to get it to update its disc id when the disc is next altered so that another machine isn't mislead into believing that a disc is the same where, in fact, it has changed.

Here's an example of the interactions that may occur:

A disc is inserted
The user clicks on the disc icon
ADFSFiler asks the Filer to open a directory viewer The Filer asks FileSwitch for a directory enumeration of that disc FileSwitch asks FileCore what type of thing $ is of that disc FileCore mounts the disc using ADFS, say, getting the disc's physical

        parameters (sector size, density etc)

        returns to FileCore.

        type corresponding to the MultiFS.

The main point of interest here is:

FileCore requests that MultiFSs try to identify this disc A MultiFS identifies the disc, fills in the disc id and other details then

        returns to FileCore.

That is, the MultiFS returns a disc id to FileCore. It is assumed that from this point on FileCore will be kept up to date as to what the disc id is. If there is a change to the disc id and FileCore is not informed, then FileCore will refuse to match that disc with its internal record resulting in continuous 'Please insert disc X' messages whenever the user tries to access files on it. This is clearly undesirable. So, it is the responsibility of all MultiFSs to inform their host filing systems whenever a disc's id has changed for whatever reason using OSArgs_ImageStampIs:

OSArgs_ImageStampIs (8) In:
r0=8
r1=file handle
r2 = new image stamp
Out:
regs preserved

OK, when and how should a MultiFS change an image's stamp? A MultiFS should change an image's stamp in the following circumstances: The first time an image is changed after:

        It has just been opened
        The MultiFS has been informed that it should update the image stamp
                after next update using fsfunc_StampImage(0)

When an image is stamped the update should be flushed (OS_Args 255) and the host filing system informed of the new value using OSArgs_ImageStampIs. Even though it is likely that only the host filing system will have issued fsfunc_StampImage the MultiFS should still call OSArgs_ImageStampIs to inform the host filing system of the change.

fsfunc_StampImage (32) In:
r0=32
r2=sub reason
0 Stamp after next update
1 Stamp now
r6=image handle
Out
regs preserved

When a MultiFS receives this it should either flag the image as needing a new id when next updated (r2=0), or give the image a new id now (r2=1). Note that the 'stamp after next update' is the same state that an image should be in after fsfunc_NewImage, or, more aptly, fsfunc_NewImage should leave an image in the 'stamp after next update' state. If stamp now is requested the image should be stamped, flushed, and the host filing system informed of the updated stamp.