Patrick Haller wrote in a message to Mike Bilow:

 PH> I've got certain doubts on that:the CDI-caches which are
 PH> maintained between kernel and IFS. I ran into the problem
 PH> that CDI caches are not invalidated 100% reliably under
 PH> unfortunate circumstances. I was unable to track this down
 PH> completely.

This is a known bug.  OS/2 expects that ISO-9660 media really will comply
with the standard, and a common error when burning CD-ROM disks is to set
the volume serial number to something stupid, such as all zeroes or all
ones. Formally, the volume serial number must be unique across any two
disks whose data may differ.  You can get the same effect under OS/2 with
floppy disks.

 PH> Second, to enhance OS/2's IO capability regarding the IFS, I
 PH> rather dislike to implement new features via FSCtl. I
 PH> _really_ think IBM should enhance the interface by a few
 PH> standard functions. Anyway, I fear I can't handle writing my
 PH> own IFS ... :)

An IFS is a driver of a sort, and it has access to the DevHelp services. 
It can therefore participate in inter-driver communication (IDC), although
this is a bit unorthodox.  You can even make a standard driver whose job is
to get IDC calls from the IFS; LAN Server's fault-tolerance (DISKFT.SYS)
works this way. In the extreme case, you could have your IFS send down the
GDT selectors for its data space and allow the IDC driver to spy privately
on the IFS.

 PH> Yes. Perhaps I should extend my DevCon subscription to 
 PH> DevCon+DDK.

It is worth the extra money for the docs alone.

 PH> Or could anyone make the LOCKDRV-sources available for me ? 
 PH> (FTP preferable)

I believe that you can get the LOCKDRV source from FTP.ADAPTEC.COM, but you
would not have enough to build the driver without the IBM DDK header files.
 
-- Mike


---