Filter manager attach.

First, how are you installing the mini??? Last week someone was trying
to install the filter via code instead of the inf file.
Is this how your doing it? Curious, but was one of the WDK samples used
as a code base, if so, which one?

Have you tested the samples such as Scanner - as written does it attach
correctly? If so, you need to start to compare and
contrast your code against the samples. If scanner doesn’t auto attach,
you need to check your OS or try on a different
machine.

It sounds almost like your writing code to ‘attach’ instead of letting
fltmgr do it’s own (and correct) thing. Some of your wording
makes it sound like your confusing fltmgr technology with legacy
technology regarding attachments…

ganesh pashupathi wrote:

Hi,

Please accept my apologies but in spite of your patient help I was not
able to solve the problem. (I currently have a work around at the user
mode level but this will require restrictions on the users who want to
use my mini-filter.)

I have tried reading several documentation but I am not able to figure
how to attach my mini-filter to the newly created device to which
filter manager would not attach if filter manager is loaded before the
creation of the device (This is as seen in the Device tree utility).

In my mini-filter I can find the driver object of the driver that is
creating the new device. From there I can enumerate the device objects
created by the driver and also find the device to which I have to
attach. I tried creating my own device and attaching this device to
the newly created device. The device that I created attaches fine to
the device that I want to attach to. I also get calls on my device.
But when I call the lower driver I get a crash.

But according to the documentation the mini filter must be attached
through the filter manager. So I don’t think this is the way to go about.

Please help me on this.

Thanks a lot,
~ganesh

On Thu, 17 May 2007 ganesh pashupathi wrote :
>Hi,
>
>I am still stuck at the rename issue. How does filter manager attach
to various devices?
>
>Also can I ask filter manager to attach to a device if it has not
attached?
>
>Kindly help.
>
>Thanks a lot,
>~ganesh
>
>—
>Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
>You are currently subscribed to ntfsd as: unknown lmsubst tag
argument: ‘’
>To unsubscribe send a blank email to xxxxx@lists.osr.com

2007-1-R-C-0217#ADWSIG0001
http:
>
>
> — Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17 You are currently
> subscribed to ntfsd as: unknown lmsubst tag argument: ‘’ To
> unsubscribe send a blank email to xxxxx@lists.osr.com</http:>

Hello m,

Many thanks for your reply.

I am installing my mini-filter with the help of an inf file. My filter is based on the null filter in the mini filter samples. The instance.flag is set so as to allow automatic attachments. Also after my filter is loaded and I newly attach a floppy disk or USB drive my filter automatically gets attached to them through the filter manager and gets called.

My problem starts when I start integrating with the Rational Clearcase MVFS driver.

My filter is loaded at system startup. Thus filter manager will attach to all the devices that are created at that moment in time. It will also attach to devices that are created at a later point in time for e.g. USB, Floppy. Thus my filter will receive the callbacks.

Now the machine has booted and I login into the machine. When I double click on a mapped drive created by Clearcase e.g. Z: in the device tree utility I can see a new device being added under the mvfs driver and filter manager is not attached to it.

If however I make my driver a demand start driver, then access Z: (new device is attached) and then load my mini-filter filter manager happily attaches to this device. I can see this in device tree utility.

I have tested the behavior with the sample mini-filters. I have also tested the behavior with file spy utility (both as legacy driver and as mini-filter) and filemon as well. It is the same as I can see with my mini-filter.

I could get much of this understanding mainly due to Lyndon C. and others as well on the OSR list.

Now since filter manager does not attach to this device (if the device was created after the filtermanager was loaded) I was looking for some alternative solution. I was reading the CDO filter code and the sfilter code and thought of trying this out. But I think this is not the way to go.

Kindly provide me with some help.

Thanks in advance,
~ganesh

Well, I have no idea what the problem is so I’m just going to start
making things up… :slight_smile:

First, MVFS is not listed in the headers as a supported file system type
for fltmgr…

Second, the last parameter for InstanceSetup’s callback is for the
volume file system type.
Keeping this in mind leads me too this quote from the doc’s for
PFLT_INSTANCE_SETUP_CALLBACK:

“If this routine returns an error or *warning* NTSTATUS code, the
minifilter driver instance *is not attached* to the given volume.”

Thus, you may not be attaching due to a warning that is something like
“warning, unsupported filesystem type”…

Therefor, perhaps if you get rid of your InstanceSetup Callback, maybe
you’ll attach???

Why this would differ for a driver configured for manual attach vs
automatic - well, that’s where my
bs begins to fall apart…

Maybe if you give it a try you’ll get lucky…

xxxxx@rediffmail.com wrote:

Hello m,

Many thanks for your reply.

I am installing my mini-filter with the help of an inf file. My filter is based on the null filter in the mini filter samples. The instance.flag is set so as to allow automatic attachments. Also after my filter is loaded and I newly attach a floppy disk or USB drive my filter automatically gets attached to them through the filter manager and gets called.

My problem starts when I start integrating with the Rational Clearcase MVFS driver.

My filter is loaded at system startup. Thus filter manager will attach to all the devices that are created at that moment in time. It will also attach to devices that are created at a later point in time for e.g. USB, Floppy. Thus my filter will receive the callbacks.

Now the machine has booted and I login into the machine. When I double click on a mapped drive created by Clearcase e.g. Z: in the device tree utility I can see a new device being added under the mvfs driver and filter manager is not attached to it.

If however I make my driver a demand start driver, then access Z: (new device is attached) and then load my mini-filter filter manager happily attaches to this device. I can see this in device tree utility.

I have tested the behavior with the sample mini-filters. I have also tested the behavior with file spy utility (both as legacy driver and as mini-filter) and filemon as well. It is the same as I can see with my mini-filter.

I could get much of this understanding mainly due to Lyndon C. and others as well on the OSR list.

Now since filter manager does not attach to this device (if the device was created after the filtermanager was loaded) I was looking for some alternative solution. I was reading the CDO filter code and the sfilter code and thought of trying this out. But I think this is not the way to go.

Kindly provide me with some help.

Thanks in advance,
~ganesh


Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: matt-martin@tx.rr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Hi m,

Thanks for your reply.

My instance setup method never got called when it exists and the new device is created after filter manager is loaded. I had also tried removing the method but the behavior is still the same. Also, even when my filter is not present on the system and I change the registry key (AttachWhenLoaded) of filtermanager so that it attaches on load I can see that filter manager does not attach to the device if the device was created after filter manager load.

In the device tree utility at first I can see 2 devices created by this driver (\Filesystem\Mvfs).

  1. \device\mvfs - Type(FILE_DEVICE_NETWORK_FILE_SYSTEM) and is identified by Fltmgr as a volume (Can see it in the output of Fltmc volumes).
  2. Unnamed - Type(FILE_DEVICE_NETWORK_FILE_SYSTEM) and cannot be seen in the output of Fltmc volumes.
  3. The new device (Unnamed) created after filter manager is already loaded - Type (FILE_DEVICE_NETWORK_FILE_SYSTEM) and cannot be seen in the output of the Fltmc volumes. I am not sure if this is a VDO or a CDO.

Thanks a lot.
~ganesh