Tony,
Thanks for the interesting scenarios. I do agree that we need to document this better.
For now I have no plans for removing this code from sfilter but I think it is good to point out to everyone that unless you have a very good reason for doing so (and if you do I would be interested in knowing what it is) there is no reason to have your filter attach to the file system recognizers. It is an unnecessary complication. Of course all of this goes away with the filter manager.
Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no rights
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Wednesday, October 13, 2004 2:50 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Bug in SFilter?
Neal,
In all fairness, you also see the LOAD request - and in my experience that is the operation truly of interest if/when filtering the recognizers. There are certain issues that arise based upon the load ordering of file system drivers, and this is one technique for observing when a file system of interest is to be loaded.
For example, we had an instance where we had to watch the load order of NTFS. If the NTFS file system were to load after our file system, all of our subsequent mount calls were eliminated because NTFS would attempt to retrieve its disk signature - from a WORM device. If one of the sectors NTFS read was not yet recorded (which did happen from time to time) it would return a non-recoverable I/O error, causing the I/O Manager to stop trying to mount the volume. Thus, we controlled the load order quite carefully and when NTFS loaded, we would deregister and then re-register, ensuring correct ordering of our file system vis-?-vis NTFS.
I have also seen similar issues surrounding support for CDFS/UDFS for customers building UDF file system drivers.
Finally, of course, I started teaching this technique years ago before the registration notification API became available in the IFS Kit (sticking with that goal of “use no undocumented APIs”).
None of these mean that you should leave the code in sfilter, but it might be worth an article explaining why it shouldn’t be necessary to filter the file system recognizers and the alternatives for doing so.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Neal Christiansen
Sent: Wednesday, October 13, 2004 1:03 AM
To: ntfsd redirect
Subject: RE: [ntfsd] Bug in SFilter?
Up to this point I have never seen a good reason for a filter to attach
to the file system recognizers since the only operation you see is a
MOUNT request. I have been tempted more then once to remove that code
from sfilter but have left it in for completeness.
Does anyone have a good reason for filtering the recognizers? I ask
because this is not currently an option available to a minifilter.
Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no
rights
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jamey Kirby
Sent: Tuesday, October 12, 2004 1:41 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Bug in SFilter?
Here is how we handle the load notification:
static NTSTATUS FsLoadFileSystemFilter(PDEVICE_OBJECT DeviceObject, PIRP
Irp)
{
NTSTATUS ntStatus = STATUS_SUCCESS;
PFS_FILTER FsFilterExtension;
FsFilterExtension = (PFS_FILTER)(DeviceObject->DeviceExtension);
KdPrint((“Recognizer is asking the real filesystem to take
over\n”));
IoCopyCurrentIrpStackLocationToNext(Irp);
// Detach (maybe temporarily) from the recognizer’s device object
which
will
// soon die
IoDetachDevice(FsFilterExtension->TargetDeviceObject);
// Pass the request down to the recognizer
ntStatus = CallDriverSync(FsFilterExtension->TargetDeviceObject,
Irp);
if (!NT_SUCCESS(ntStatus))
{
KdPrint((“Recognizer unable to load the filesystem\n”));
// The load was not successful. Simply reattach to the
recognizer
// driver in case it ever figures out how to get the
driver
loaded
// on a subsequent call.
if( IoAttachDeviceToDeviceStack(DeviceObject,
FsFilterExtension->TargetDeviceObject) == NULL )
{
// Re-attach failed
ntStatus = STATUS_DEVICE_NOT_READY;
KdPrint((“re-attach failed!\r\n”));
IoDeleteDevice(DeviceObject);
}
}
else
{
KdPrint((“Recognizer loaded the real file system\n”));
IoDeleteDevice(DeviceObject);
}
Irp->IoStatus.Status = ntStatus;
IoCompleteRequest(Irp, IO_NO_INCREMENT);
return ntStatus;
}
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Molly Brown
Sent: Tuesday, October 12, 2004 1:21 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Bug in SFilter?
Hi Razvan,
I gave this a try and, yes, there is a bug in Sfilter. I didn’t need to
run OSR’s DiskView to hit the problem. Once I enabled Sfilter to attach
to the file system recognizers (it does not by default), I would
bugcheck as the machine booted up and recognized the CD in the CDROM
drive.
The fix is to call IoDetachDevice on the Sfilter device object just
before calling IoCallDriver to pass through the IRP_MN_LOAD_FILE_SYSTEM
irp.
This bug was introduced when the Sfilter sample was changed to run on
Windows 2000 or later (that change occurred in the XP SP1 IFS Kit). The
W2K code path in the Sfilter sample does the correct thing, so it is
only the XP and greater path that needs to be fixed. The filespy sample
does not contain this bug.
I will get this fixed for the next version of the IFS Kit.
Thanks for reporting the problem,
Molly Brown
Microsoft Corporation
This posting is provided “AS IS” with no warranties and confers no
rights.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Razvan Hobeanu
Sent: Tuesday, October 12, 2004 2:04 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Bug in SFilter?
I think there is a bug in the sfilter sample from the IFS KIT 2003.
In the IRP_MN_LOAD_FILE_SYSTEM dispatch routine, the XP-or-later version
does not detach before sending the request down. Due to this, the system
bugchecks with IRQL_NOT_LESS_OR_EQUAL.
I didn’t figure out the cases when this occurs. Notice that filters
built on sfilter may never experience this error during testing.
However, try testing sfilter by loading the OSR DiskView utility and the
bugcheck will come up.
Can anyone confirm this?
Best regards,
Razvan
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
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
__________ NOD32 1.860 (20040903) Information __________
This message was checked by NOD32 antivirus system.
http://www.nod32.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
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
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