I’m looking for suggestions to my problem. My mini-filter driver currently monitors IRP_MJ_CREATE, IRP_MJ_WRITE, and IRP_MJ_SET_INFORMATION types. But I want to filter out IRP_MJ_WRITE messages for directories as they are noise I’m not concerned with.
My first thought was to call FltQueryInformationFile() from my PreOp callback, and if the object turns out to be a directory then ignore that event. However, MSDN says to call IoGetTopLevelIrp() first to determine if it’s safe, and a significant portion of the time this API is telling me it’s not safe to call.
I can’t call FltQueryInformationFile() from my PostOp callback as this function requires PASSIVE_LEVEL and the PostOp isn’t guaranteed at that level.
My last thought is I have a worker thread which occasionally writes all the events to a file. Before this thread writes an IRP_MJ_WRITE event it could check if the object is a file or folder. But this would require the object to be reopened to acquire a FILE_OBJECT, and that’s a lot of opening and closing of files since IRP_MJ_WRITE messages are frequent.
Is there a better way to determine file versus folder that I’m not aware of, preferable one which is safe from Pre/PostOp? Thanks.
I think you could call FltIsDirectory(). This information is cached by
filter manager internally and so you can simply call it during the preOp for
any op and see if it’s interesting to you or not. Should be even faster than
caching it in your own stream context…
Thanks,
Alex.
You can call FtlisDirectory in your post-op create callback and store the
results in your stream context. Or just not attach a stream context if you
are not interested in monitoring directories.
BTW, post-op create is called in PASSIVE_LEVEL.
G.
On Fri, Nov 5, 2010 at 3:42 PM, Alex Carp wrote:
> I think you could call FltIsDirectory(). This information is cached by
> filter manager internally and so you can simply call it during the preOp
> for
> any op and see if it’s interesting to you or not. Should be even faster
> than
> caching it in your own stream context…
>
> Thanks,
> Alex.
>
>
> —
> 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
>
–
Before you criticize someone, you should walk a mile in their shoes. That
way, when you criticize them, you’re a mile away and you have their shoes.
I’m not sure caching is better than querying every time since filter manager
caches it its internal stream context and so by caching it yourself you
waste some memory and CPU cycles. Hence my point about how it should be
faster than caching it in your own stream context…
Thanks,
Alex.
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gilad Wolff
Sent: Friday, November 05, 2010 4:19 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Filtering out IRP_MJ_WRITE for Directories
You can call FtlisDirectory in your post-op create callback and store the
results in your stream context. Or just not attach a stream context if you
are not interested in monitoring directories.
BTW, post-op create is called in PASSIVE_LEVEL.
G.
On Fri, Nov 5, 2010 at 3:42 PM, Alex Carp
wrote:
I think you could call FltIsDirectory(). This information is cached by
filter manager internally and so you can simply call it during the preOp for
any op and see if it’s interesting to you or not. Should be even faster than
caching it in your own stream context…
Thanks,
Alex.
—
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
–
Before you criticize someone, you should walk a mile in their shoes. That
way, when you criticize them, you’re a mile away and you have their shoes.
— 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