I am the author of a file system driver, which in general works well with third party minifilters. However some minifilters cause occasional problems due to incompatibilities with my file system driver or other reasons. Often I resolve these problems by working directly with the minifilter authors or by developing work arounds in my file system driver; however this is not always possible.
I have been mulling over the idea of controlling which minifilters can attach to volumes created by my file system driver. This could manifest itself as a whitelist/blacklist scheme that:
-
Either disallows attaching a minifilter to my volumes. Ideally the filter manager would provide a way to file systems to veto the attachment of a particular minifilter to their volumes.
-
Or get notified when a minifilter attaches to my volumes. In this less ideal scenario a file system would be able to detect the attachment of a particular minifilter and detach it.
I seek the wisdom of the OSR crowd on this. I can think of a few schemes of my own ranging from hacky "hijack InstanceSetupCallback and return STATUS_FLT_DO_NOT_ATTACH" to milder "enumerate minifilters using FltEnumerateInstanceInformationByVolumeName and call FltDetachVolume" on them.
I understand that the default response might be "don't do this" and that my file system driver should just work with all minifilters. I strive to achieve interface compatibility with NTFS, but this is not possible in all cases. Many of these problems occur because some minifilters seem to assume that they will only ever attach to an NTFS (or at least MSFT) file system and cause subtle failures when attaching to something else.
Finally and if any MSFT devs are reading this: please consider giving the ability to file system drivers to veto minifilter attachments.