We have a Activity monitor filter (MiniSpy like Driver). requirement is to
ignore certain folder paths, As far as possible we do not want to maintain
and perform string comparison in our filter driver. Is there any way we can
achieve exclusion of paths without string comparison?
Set a StreamContext in post create and check it?
If you are wanting to do FltQuerynameInformation it is usually better to make the decision in post create anyway (in which case FltMgr will do the work of caching for you).
One way or another I think you are doomed to do string comparison.
As an aside watch out for hard links and their post vista homologue softlinks on the same device (which you need to work quite hard to distinguish between in a filter driver).?
“Manav Deshmukh” wrote in message news:xxxxx@ntfsd…
We have a Activity monitor filter (MiniSpy like Driver). requirement is to ignore certain folder paths, As far as possible we do not want to maintain and perform string comparison in our filter driver. Is there any way we can achieve exclusion of paths without string comparison?
I agree with Rod, you’re going to probably need to do some string
comparison.
Do you intend to track files across renames (for example, file c:\foo.txt
gets renamed to c:\bar\foo.txt, where you don’t monitor c:\ but you do
monitor c:\bar .) ? If so you’re going to have to keep track of other things
as well. Here is a quick list of the top of my head: renames, superseding
renames, directory renames, transaction commits and rollbacks and there are
more.
I would also suggest the StreamHandleContext type of contexts (as opposed to
the StreamContext), because for files that have hardlinks you would get the
same StreamContext regardless of the name the file is opened with, and you
might only care about one of the links to the file and not the other. You
could use StreamContexts provided that you implement your own logic to keep
track of whether each handle is in the monitored namespace.
In the very simple case where you don’t care about renames and the set of
directories you want to track is somewhat static and you don’t need to
support all filesystems, you could do something like setting EAs (FAT and
NTFS as far as I know… not sure if they work on folders) or alternate data
streams (NTFS only, work on folders) on the folders and then in the
IRP_MJ_CREATE path for a file you could determine from the parent folder
whether you need to log this or not. This would allow a user mode app to set
whether a folder needs to be watched or not. Also, depending on your
requirements, you might need to implement logic in postCreate for folders to
inherit the “do not track” logic from their parent folder so that you don’t
have to set it for each and every child of a folder that you don’t intend to
track. But this way you would implement it without any string comparison in
your driver (I think).
Thanks,
Alex.
“Alex Carp” wrote in message
news:xxxxx@ntfsd…
>you could do something like setting EAs (FAT and NTFS as far as I know…
>not sure if they work on folders)
No EAs on FAT32, from the FAT source early in create:
//
// If this is a fat32 volume, EA’s are not supported.
//
if (EaBuffer != NULL &&
FatIsFat32(Vcb)) {
try_return( Iosb.Status = STATUS_EAS_NOT_SUPPORTED );
}
The approach we’ve taken is to tag directories with a stream if possible and
use a file otherwise. The trick then becomes figuring out of the target FS
supports streams or not, which gets really annoying over the network (you’d
be amazed what kind of errors those appliances out there return when you try
to create or open a stream).
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Alex Carp” wrote in message
news:xxxxx@ntfsd…
I agree with Rod, you’re going to probably need to do some string
comparison.
Do you intend to track files across renames (for example, file c:\foo.txt
gets renamed to c:\bar\foo.txt, where you don’t monitor c:\ but you do
monitor c:\bar .) ? If so you’re going to have to keep track of other things
as well. Here is a quick list of the top of my head: renames, superseding
renames, directory renames, transaction commits and rollbacks and there are
more.
I would also suggest the StreamHandleContext type of contexts (as opposed to
the StreamContext), because for files that have hardlinks you would get the
same StreamContext regardless of the name the file is opened with, and you
might only care about one of the links to the file and not the other. You
could use StreamContexts provided that you implement your own logic to keep
track of whether each handle is in the monitored namespace.
In the very simple case where you don’t care about renames and the set of
directories you want to track is somewhat static and you don’t need to
support all filesystems, you could do something like setting EAs (FAT and
NTFS as far as I know… not sure if they work on folders) or alternate data
streams (NTFS only, work on folders) on the folders and then in the
IRP_MJ_CREATE path for a file you could determine from the parent folder
whether you need to log this or not. This would allow a user mode app to set
whether a folder needs to be watched or not. Also, depending on your
requirements, you might need to implement logic in postCreate for folders to
inherit the “do not track” logic from their parent folder so that you don’t
have to set it for each and every child of a folder that you don’t intend to
track. But this way you would implement it without any string comparison in
your driver (I think).
Thanks,
Alex.
A practical idea is to put the relevant part of the folder paths that are to be ignored inside regular expressions and use a function like FsRtlIsNameInExpression to make this as simple as possible. Admitted that is still a form of string comparison.
//Daniel
“Manav Deshmukh” wrote in message news:xxxxx@ntfsd…
We have a Activity monitor filter (MiniSpy like Driver). requirement is to ignore certain folder paths, As far as possible we do not want to maintain and perform string comparison in our filter driver. Is there any way we can achieve exclusion of paths without string comparison?
Hi Scott,
Thanks, for some reason I though EAs were supported on FAT… I guess this
narrows it down even more…
Thanks,
Alex.
Thanks all. My min filter driver supports only NTFS. I was thinking of any
file/folder attributes that I can use (without triggering backup, or updates
to file write /modify time) in user mode and then check in Kmode.
Looks like reparse point is one possible method, User mode application can
set a reparse point but If a file system filter is not found, the file open
operation fails. That is what I really do not want.
Looks like there are very few choices and I really need to do string compare
and maintain / protect string list which I wanted to avoid.
On Fri, Oct 1, 2010 at 1:33 AM, Rod Widdowson wrote:
> Set a StreamContext in post create and check it?
>
> If you are wanting to do FltQuerynameInformation it is usually better to
> make the decision in post create anyway (in which case FltMgr will do the
> work of caching for you).
>
> One way or another I think you are doomed to do string comparison.
>
> As an aside watch out for hard links and their post vista homologue
> softlinks on the same device (which you need to work quite hard to
> distinguish between in a filter driver).?
>
> “Manav Deshmukh” wrote in message news:xxxxx@ntfsd…
>
> We have a Activity monitor filter (MiniSpy like Driver). requirement is to
> ignore certain folder paths, As far as possible we do not want to maintain
> and perform string comparison in our filter driver. Is there any way we can
> achieve exclusion of paths without string comparison?
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
FAT != FAT32
…
“Alex Carp” wrote in message
news:xxxxx@ntfsd…
> Hi Scott,
>
> Thanks, for some reason I though EAs were supported on FAT… I guess this
> narrows it down even more…
>
> Thanks,
> Alex.
>
>