cache manager

[amitr0-2]

tony,

Fast I/O is a misnomer ? it is not necessarily any faster than normal I/O
these days and I have seen it be slower to support Fast I/O. Do >not read
too much into a 10+ year old name.

has the IOmanager architechure changed internally from NT4.0 to 2K so that
the original purpose of FastIo is not that important anymore. If I remember
correctly, there was a lot of speculation that FastIO was actuallya last
minute hack to increase system throughput, though never confirmed by MS, I
guess.

You say that it is not necessarily faster than normal IO. Sir, can you take
some pain and explain as to why this happens?

amitr0

[Bedanto]

Hi Tony,

Normally, caching is not established until first I/O because the call to
set up (CcInitializeCacheMap) is “expensive” when many file open >operations
do not involve I/O.

This I read in Nagar’s book. However, it was not clear to me, how the system
starts redirecting cache manager calls to FastIo entry points after
CcInitializeCacheMap. The sequence of steps is what I cannot comprehend.

Lyndon,

I don’t know where you are located, however i can guess that you are not
from Asia. Here the situation is far different. You cannot imagine the
constraints we face when it comes to packages offered by firms. Let alone
company sponsored trips to attend seminars. This topic has been discussed
time and again in this group, so no use repeating it.

All I can tell you is that we asians have to make do with waht we have,
which is our intellect and patience to read up thousands of webpages and OSR
threads to acquire the knowledge. Sometimes it is impossible, sometimes it
is way too much time consuming, but that cannot be helped.

You can not expect free help; you can just be grateful when it is given.

I did not expect help, just polled the question to see if someone is knd
enough to take some time out and answer it. In fact, if you have noticed, I
have always thnked everyone who answered my queries.

You should invest in the excellent driver and file systems courses.

Thus these type of stametents who mean nothing to me, as we here dont have
that much infrastructure to do it.

You should remember all you have learned from the sfilter and filespy code;
and forget much of what
you have also learned from the filemon code.

Why do you suggest that I forget what I have learned from the filemon
code??? Is there something seriously wrong with it?

You should not consider SSDT hooking; the “guru” gave you bad advice.

The rason the guru suggested this approach ( as i understand it) is because
he was sure some IO would go undetected in the filter driver approach, and
some would be in arbitrary context, as in the case of paging IO. However,
in SSDT approach since Nt* calls are tracked, all these calls would be
tapped before IOmanager, r other s mess with them.

Can you guarantee any other technique that is going to give me all IO calls
(even the ones that are directed to the cache manager) through a filter
driver?

Lastly, and not least…

thank you all once again, and I meant no offence in my mail, may be a few
lines might sound harsh, but they were not meant to be so…

bedanto

[OSR_Community_User]

Actually, it is all based upon FileObject->PrivateCacheMap.

This value is normally zero when the FO is first created. Then when you
call CcInitializeCacheMap it sets this pointer to this file object’s
private cache map. Thus, when the I/O Manager decides if it can call
fast I/O it looks at FileObject->PrivateCacheMap (and some other things
as well).

If fast I/O isn’t possible on this file, it (I/O Manager) sends an IRP.

Six years ago I had someone at MS ask about the impact of removing the
I/O functions from the fast I/O vector; he claimed that at that point
the measured benefit (using the specific key benchmark) was under 3% (it
saves the allocation of an IRP but complicates the I/O Manager’s logic a
bit.)

About a year before THAT we’d built a filter that turned off fast I/O
entirely and were surprised to see that under some circumstances the
system was as much as 33% faster on large file copy operations (with
fast I/O disabled.) I never bothered to figure out why.

MOST of the Fast I/O entry point vector has nothing to do with I/O at
this point - it is related to locking or attribute queries. Oddly
enough, the biggest winner for an FSD in terms of performance is the
Query Network Open operation - because it collapses four separate IRP
calls into one call. THAT’s a big win relative to the overall operation
and the I/O Manager uses this fast I/O entry point, although I recall
that it was originally added for SRV performance.

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com

Looking forward to seeing you at the next OSR File Systems class in
Boston, MA April 18-21, 2006 (note new date - MS scheduled plugfest the
same week again.)

---

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bedanto
Sent: Thursday, February 23, 2006 1:30 AM
To: ntfsd redirect
Subject: Re: [ntfsd] cache manager

Hi Tony,

Normally, caching is not established until first I/O because the call
to set up (CcInitializeCacheMap) is “expensive” when many file open
operations do not involve I/O.

This I read in Nagar’s book. However, it was not clear to me, how the
system starts redirecting cache manager calls to FastIo entry points
after CcInitializeCacheMap. The sequence of steps is what I cannot
comprehend.

Lyndon,

I don’t know where you are located, however i can guess that you are not
from Asia. Here the situation is far different. You cannot imagine the
constraints we face when it comes to packages offered by firms. Let
alone company sponsored trips to attend seminars. This topic has been
discussed time and again in this group, so no use repeating it.

All I can tell you is that we asians have to make do with waht we have,
which is our intellect and patience to read up thousands of webpages and
OSR threads to acquire the knowledge. Sometimes it is impossible,
sometimes it is way too much time consuming, but that cannot be helped.

You can not expect free help; you can just be grateful when it is
given.

I did not expect help, just polled the question to see if someone is knd
enough to take some time out and answer it. In fact, if you have
noticed, I have always thnked everyone who answered my queries.

You should invest in the excellent driver and file systems courses.

Thus these type of stametents who mean nothing to me, as we here dont
have that much infrastructure to do it.

You should remember all you have learned from the sfilter and filespy
code;
and forget much of what
you have also learned from the filemon code.

Why do you suggest that I forget what I have learned from the filemon
code??? Is there something seriously wrong with it?

You should not consider SSDT hooking; the “guru” gave you bad advice.

The rason the guru suggested this approach ( as i understand it) is
because he was sure some IO would go undetected in the filter driver
approach, and some would be in arbitrary context, as in the case of
paging IO. However, in SSDT approach since Nt* calls are tracked, all
these calls would be tapped before IOmanager, r other s mess with them.

Can you guarantee any other technique that is going to give me all IO
calls (even the ones that are directed to the cache manager) through a
filter driver?

Lastly, and not least…

thank you all once again, and I meant no offence in my mail, may be a
few lines might sound harsh, but they were not meant to be so…

bedanto

— 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

[amitr0-2]

Tony,

Very informative mail, added a lot to my knowledge base. Thanks a ton fro
sahring your expertise.

Best regards,

amitr0

[OSR_Community_User]

I’m going to point out that system call hooking misses I/O operations
that a file system filter driver does not, not the other way around.
ANYTHING that comes through the system call interface must go through
the I/O Manager and then into the driver stack. However, there are
sources of I/O (SRV, NFS, NTVDM, DFS, etc.) that do NOT go through the
system call interface to perform their I/O operations.

The best example is that SRV constructs and sends it’s own IRP requests
to the file systems. It does send those down the storage stack, but
does that below the system call table.

But there are also functions that do not use system calls - witness
IoCreateFile which is a documented IFS Kit call but does not issue a
system service call.

These ARE caught by a file system filter driver. The person who thinks
that a system call trap will capture calls that a file system filter
driver misses is very much mistaken. It *is* possible for one driver to
bypass other drivers (think of using IoCreateFileSpecifyDeviceObjectHint
for example, or just simply using IoCallDriver and pointing it to the
driver you want to invoke, bypassing any filters installed.) Normally
such behavior is a bug, but I have seen it exploited deliberately in
order to bypass other filters (to work around bugs for instance, or to
eliminate interoperability issues.)

As for classes in Asia, I’ve taught multiple times in Asia, both public
and private classes. If there is demand for a file systems class, and
if management values your efforts then they would be willing to pay for
such a class. However, the real issue here is that management often
does not understand the extremely complex nature of file systems
development. I’ve also seen that the budgeting process - even in US
companies - allocates very little money for training, not realizing that
the cost of “on the job training” is very high in this space - and
Windows Vista is going to make that even higher with more new features
in our space than I’ve seen since NT 4.0. (I’ll also mention that I’m
writing this from my hotel room in Seoul.)

Regards,

Tony

“Have laptop, will travel…”

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com

Looking forward to seeing you at the next OSR File Systems class in
Boston, MA April 18-21, 2006 (note new date - MS scheduled plugfest the
same week again.)

---

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bedanto
Sent: Thursday, February 23, 2006 1:30 AM
To: ntfsd redirect
Subject: Re: [ntfsd] cache manager

Hi Tony,

Normally, caching is not established until first I/O because the call
to set up (CcInitializeCacheMap) is “expensive” when many file open
operations do not involve I/O.

This I read in Nagar’s book. However, it was not clear to me, how the
system starts redirecting cache manager calls to FastIo entry points
after CcInitializeCacheMap. The sequence of steps is what I cannot
comprehend.

Lyndon,

I don’t know where you are located, however i can guess that you are not
from Asia. Here the situation is far different. You cannot imagine the
constraints we face when it comes to packages offered by firms. Let
alone company sponsored trips to attend seminars. This topic has been
discussed time and again in this group, so no use repeating it.

All I can tell you is that we asians have to make do with waht we have,
which is our intellect and patience to read up thousands of webpages and
OSR threads to acquire the knowledge. Sometimes it is impossible,
sometimes it is way too much time consuming, but that cannot be helped.

You can not expect free help; you can just be grateful when it is
given.

I did not expect help, just polled the question to see if someone is knd
enough to take some time out and answer it. In fact, if you have
noticed, I have always thnked everyone who answered my queries.

You should invest in the excellent driver and file systems courses.

Thus these type of stametents who mean nothing to me, as we here dont
have that much infrastructure to do it.

You should remember all you have learned from the sfilter and filespy
code;
and forget much of what
you have also learned from the filemon code.

Why do you suggest that I forget what I have learned from the filemon
code??? Is there something seriously wrong with it?

You should not consider SSDT hooking; the “guru” gave you bad advice.

The rason the guru suggested this approach ( as i understand it) is
because he was sure some IO would go undetected in the filter driver
approach, and some would be in arbitrary context, as in the case of
paging IO. However, in SSDT approach since Nt* calls are tracked, all
these calls would be tapped before IOmanager, r other s mess with them.

Can you guarantee any other technique that is going to give me all IO
calls (even the ones that are directed to the cache manager) through a
filter driver?

Lastly, and not least…

thank you all once again, and I meant no offence in my mail, may be a
few lines might sound harsh, but they were not meant to be so…

bedanto

— 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

[amitr0-2]

Dear Tony,

Even I am from Asia, and what you tell about budgeting is a fact here.
Management just doesn’t understand teh complexity of writing kernel mode
code. To them, getting the free code and jacking it up to their needs is a
quicker appraoch, and the 2 guys out of the 10 who attempt this and suceed
are given teh appraisals where as the others who tried, but were unfortunate
enough not to be able to grasp the dirty code hacks and quick fixes are
kicked out or branded as teh less gifted ones!!!

I remember when I started a year back ( yes, I am still a novice ), all I
had to go on with were some videos which came with the IFS kit and the OSR
web site, the rebukes from the seniors for asking stupid questions (and I
still do ask a lot of stupid questions). Guess that the part of a learning
curve.

Good luck Bedanto and others. Tony, Ladislav and their kind are always there
to help, all you gotta do is ignore their rebukes and get as much
information out as you can.

amitr0

[Lyndon_J_Clarke-2]

Bedanto

I don’t know where you are located, however i can guess that you are not
from Asia.

You are correct and I am located in UK.

Here the situation is far different. You cannot imagine the constraints we
face when it comes to packages offered by firms.

I accept what you say however I can assure you that there are real
difficulties with these matters elsewhere. I was just trying to be helpful
since you appear to be at the very start of your journey.

Let alone company sponsored trips to attend seminars. This topic has been
discussed time and again in this group, so no use repeating it.

I must have missed such discussions which comes as a surprise to me, so if I
am in error, please accept my apologies.

Why do you suggest that I forget what I have learned from the filemon
code??? Is there something seriously wrong with it?

This topic has been discussed time and again in this group, so no use
repeating it

The rason the guru suggested this approach ( as i understand it) is
because he was sure some IO

The “guru” was both wrong and right but more wrong than right. In fact
neither technique can guarantee to give you all the i/o operations. For
example lots of kernel mode components do not use the system services even
for basic operations such as opening file. If you hook SSDT you see none of
this traffic however as a filter driver you might see this traffic.

Kind regards
Lyndon

[Bedanto]

>I must have missed such discussions which comes as a surprise to me, so if
I

am in error, please accept my apologies.

Lyndon, no issues, as amitr0 pointed out, we all gotta ignore the rebukes of
seniors, if we gotta learn something!!! Also, it is not possible to
understand the scenario at the other end, I cannot even begin to imagine the
problems you guys might be facing. So let it be

This topic has been discussed time and again in this group, so no use
repeating it

Gosh, sems like I missed those threads myself, I beg of you to send me the
links, if you can. It would be of great help.

The “guru” was both wrong and right but more wrong than right. In fact
neither technique can guarantee to give you all the i/o operations. For
example lots of kernel mode components do not use the system services even
for basic operations such as opening file. If you hook SSDT you see none of
this traffic however as a filter driver you might see this traffic.

Yes, I know what you mean, the SRV example which Tony gave, I already knew
of.

But is it safe to assume that if I add a file system filter, and an SSDT
level hook, then between them I can catch all types of IO?

Regards,

Bedanto

[amitr0-2]

bedanto ur guru is not all correct. all traffic from SRV goes straight to
IoCreateFile not NtCreatefile which is in SSDT. So you cannot catch them
there.

Even the filter driver is not fool proof, there are methods to bypass
portions of the stack, what can you do if someone just gets teh pointer to
the driver device below you and directly makes a call, antivirus softwares
are known to have done that.

So there is *NO* fool proof way to get all IO on the system. Maybe a hybrid
solution of a filter driver as well as an SSDT hook could work, I am not
sure.

Also remember, CD write operations will bypass your stack, this is the
current issue I am working on…thake that into account. Most CD writers
create the entire FS image in user mode and then transfer it wholly to the
disk, this is done for performance issues.

cheers.

amitrajit

[OSR_Community_User]

If you can find an I/O that you can catch with a system call hook that
you cannot see with a file system filter driver, I’d love to know what
it is.

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com

Looking forward to seeing you at the next OSR File Systems class in
Boston, MA April 18-21, 2006 (note new date - MS scheduled plugfest the
same week again.)

---

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bedanto
Sent: Thursday, February 23, 2006 5:37 AM
To: ntfsd redirect
Subject: Re: [ntfsd] cache manager

I must have missed such discussions which comes as a surprise to me, so
if I
am in error, please accept my apologies.

Lyndon, no issues, as amitr0 pointed out, we all gotta ignore the
rebukes of seniors, if we gotta learn something!!! Also, it is not
possible to understand the scenario at the other end, I cannot even
begin to imagine the problems you guys might be facing. So let it be

This topic has been discussed time and again in this group, so no use
repeating it

Gosh, sems like I missed those threads myself, I beg of you to send me
the links, if you can. It would be of great help.

The “guru” was both wrong and right but more wrong than right. In fact
neither technique can guarantee to give you all the i/o operations. For
example lots of kernel mode components do not use the system services
even
for basic operations such as opening file. If you hook SSDT you see
none of
this traffic however as a filter driver you might see this traffic.

Yes, I know what you mean, the SRV example which Tony gave, I already
knew of.

But is it safe to assume that if I add a file system filter, and an SSDT
level hook, then between them I can catch all types of IO?

Regards,

Bedanto

— 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

[Bedanto]

well actually, the closer to the caller context I tap, the better
information context i get. in fs filters it is difficult to catch high level
ops like save as, move, delete etc, all these are broken down further to
simple ops.

as for SSDT hooking, what abt cache manager calls or memory mapped file
calls? Can’t they be better tackled there. please excuse me if I am wrong, I
am just trying to assemble a jigsaw puzzle, in which many of the pieces are
missing…\

dedanto

[Dan_Partelly]

Not that I agree with methods of learning which consists of bashing this
list with
weird, repetitive, idiotic questions, but you know, this guys is right when
he says
about the big differences between west and east.

What he doesnt know, is that the differences are not so big after all , I
worked with
companies based in EU (yes, even UK), which much prefered the hack
approach,
either because:

1. Was the only way to implement something
2. Was easier to do and saved them cash .
3. Somone told them that it can be done that way and they decided they know
   better than developer. Thats it , deaf ears of management

And this mentality was found especially in sstartup companies, created
with the sole intention to develope some technology and be sold.

I also agree that is futile to tell anyone which is east of Austria to
west of Japan to go to a course FS driver development.
In some of those coutnries with 3000 USD you can live
more than a year. And imagine how big is the monthly wedge
of a developer in this case.

Let’s face it, there are 2 very different worlds. Which now come in
clashing at full power, yet with unforeseen social and economical
consequences. Just think EU and it’s Eastern Europe new members.

----- Original Message -----
From: “Lyndon J. Clarke”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Thursday, February 23, 2006 12:19 PM
Subject: Re:[ntfsd] cache manager

> Bedanto
>
>> I don’t know where you are located, however i can guess that you are not
>> from Asia.
>
> You are correct and I am located in UK.
>
>> Here the situation is far different. You cannot imagine the constraints
>> we face when it comes to packages offered by firms.
>
> I accept what you say however I can assure you that there are real
> difficulties with these matters elsewhere. I was just trying to be helpful
> since you appear to be at the very start of your journey.
>
>> Let alone company sponsored trips to attend seminars. This topic has been
>> discussed time and again in this group, so no use repeating it.
>
> I must have missed such discussions which comes as a surprise to me, so if
> I am in error, please accept my apologies.
>
>> Why do you suggest that I forget what I have learned from the filemon
>> code??? Is there something seriously wrong with it?
>
> This topic has been discussed time and again in this group, so no use
> repeating it
>
>> The rason the guru suggested this approach ( as i understand it) is
>> because he was sure some IO
>
> The “guru” was both wrong and right but more wrong than right. In fact
> neither technique can guarantee to give you all the i/o operations. For
> example lots of kernel mode components do not use the system services even
> for basic operations such as opening file. If you hook SSDT you see none
> of this traffic however as a filter driver you might see this traffic.
>
> Kind regards
> Lyndon
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to xxxxx@lists.osr.com

[amitr0-2]

hey man, what are you trying to build??? I thought it was filemon you were
trying to make, and filemon is meant to get only low level operations!!!
are you sre you dont want anything else???

[Dan_Partelly]

>> in fs filters it is difficult to catch high level ops like save as, move, delete

May I suggest to hook “Menu items” in GUI then , for thigs like SaveAs and Move, not writting kernel mode code ? Really your funny. Do you think
there is a NtNativeSaveAs() , which can be intercepted in SSDT ?

Dan

----- Original Message -----
From: Bedanto
To: Windows File Systems Devs Interest List
Sent: Thursday, February 23, 2006 12:54 PM
Subject: Re: [ntfsd] cache manager

well actually, the closer to the caller context I tap, the better information context i get. in fs filters it is difficult to catch high level ops like save as, move, delete etc, all these are broken down further to simple ops.

as for SSDT hooking, what abt cache manager calls or memory mapped file calls? Can’t they be better tackled there. please excuse me if I am wrong, I am just trying to assemble a jigsaw puzzle, in which many of the pieces are missing…\

dedanto
— 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

[Dan_Partelly]

>> as for SSDT hooking, what abt cache manager calls or memory mapped file calls?

Accept what you have been told. No they cant be better tackled at SSDT hooking level. And accept that if anyone sad you that he
can catch at SSDT level file IO which you cant see in a filter driver, then he is a idiot.

Dan

----- Original Message -----
From: Bedanto
To: Windows File Systems Devs Interest List
Sent: Thursday, February 23, 2006 12:54 PM
Subject: Re: [ntfsd] cache manager

well actually, the closer to the caller context I tap, the better information context i get. in fs filters it is difficult to catch high level ops like save as, move, delete etc, all these are broken down further to simple ops.

as for SSDT hooking, what abt cache manager calls or memory mapped file calls? Can’t they be better tackled there. please excuse me if I am wrong, I am just trying to assemble a jigsaw puzzle, in which many of the pieces are missing…\

dedanto
— 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

[amitr0-2]

…and how do u suppose that SSDT hooking is going to get u context for save
as and move???

AFAIK, every shell have native implementation of the move file op, and so
even hooking one in user land wont work if he is using a different shell.

as for save as, how do u plan to hook it by the way? a menu level hook!!!
Or would you like to hook the common dialogs GetSaveFileName call??? Both
won’t work wonders to your app.

Stick to FSFD, they are stable, safe and adhere to misrosoft policies of
extending the system, and also saves you from getting bashed up by the OSR
gurus. Also if u hook, and ur app crashes, dont expect to get help in this
forum, where as if u write an FSFD, you will get some help.

Reads my previous threads, I have discussed similar things in the past.

amitr0

[OSR_Community_User]

Tony & Peter, and OSR folk,

As Bedanto stated, “Here the situation is far different. You cannot
imagine the constraints we face when it comes to packages offered by
firms. Let alone company sponsored trips to attend seminars.”, I have to
agree with this guy.

First, not everyone’s company will pay $1,500 for airfare plus your
$2500 seminar fee, plus travel expenses (Bendanto’s case).

Second, some of us (such as myself) are hobbiest. I can’t afford
$3-4,000 out of pocket to attend an OSR seminar (that would be kinda
hard to explain to my gf or friends ).

Why not put parts of a seminar on DVD or VCD? There is a whole market
here. I bought the reprint of Rajeev’s book, but other than that, unless
you offer something else that can help me with FS drivers and filters
other than the NT Insider and this list I can’t send anymore money OSR’s
way.

I believe there is something like 36,000 members @ osronline; I bet only
a fraction have or ever will attend a live seminar. I would gladly pay
for a seminar recording, even if it was scaled down for novices such as
myself.

M.

Bedanto wrote:

Hi Tony,

>Normally, caching is not established until first I/O because the call
to set up (CcInitializeCacheMap) is “expensive” when many file open
>operations do not involve I/O.

This I read in Nagar’s book. However, it was not clear to me, how the
system starts redirecting cache manager calls to FastIo entry points
after CcInitializeCacheMap. The sequence of steps is what I cannot
comprehend.

Lyndon,

I don’t know where you are located, however i can guess that you are
not from Asia. Here the situation is far different. You cannot imagine
the constraints we face when it comes to packages offered by firms.
Let alone company sponsored trips to attend seminars. This topic has
been discussed time and again in this group, so no use repeating it.

All I can tell you is that we asians have to make do with waht we
have, which is our intellect and patience to read up thousands of
webpages and OSR threads to acquire the knowledge. Sometimes it is
impossible, sometimes it is way too much time consuming, but that
cannot be helped.

>You can not expect free help; you can just be grateful when it is given.

I did not expect help, just polled the question to see if someone is
knd enough to take some time out and answer it. In fact, if you have
noticed, I have always thnked everyone who answered my queries.

>You should invest in the excellent driver and file systems courses.

Thus these type of stametents who mean nothing to me, as we here dont
have that much infrastructure to do it.

>You should remember all you have learned from the sfilter and filespy
code;
>and forget much of what
>you have also learned from the filemon code.

Why do you suggest that I forget what I have learned from the filemon
code??? Is there something seriously wrong with it?

>You should not consider SSDT hooking; the “guru” gave you bad advice.

The rason the guru suggested this approach ( as i understand it) is
because he was sure some IO would go undetected in the filter driver
approach, and some would be in arbitrary context, as in the case of
paging IO. However, in SSDT approach since Nt* calls are tracked, all
these calls would be tapped before IOmanager, r other s mess with them.

Can you guarantee any other technique that is going to give me all IO
calls (even the ones that are directed to the cache manager) through a
filter driver?

Lastly, and not least…

thank you all once again, and I meant no offence in my mail, may be a
few lines might sound harsh, but they were not meant to be so…

bedanto
— 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

[amitr0-2]

>that would be kinda hard to explain to my gf or friends

mat as usual, I admire your quality of adding humor to these things…

cheers,
amitr0

[OSR_Community_User]

> in fs filters it is difficult to catch high level ops like save as, move,

delete etc, all these are broken down further to simple ops.

Not speaking about how bizzare this discussion is getting,
even if you hook Kernel32 API, you will not be able to detect
something like “save as”.

***************************

I respect you can’t afford something like OSR classes or IFS
plugfest.

If you have the Nagar’s book, study it well. Regardles it is outdated,
does not describe new features, does not know about filter manager
and all that jazz, it still can tell you how the whole file system
infrastructure works.

I know that reading the book is not easy for a beginner,
I had to read it 2 times to get feeling that I understand at least
something :-), but the time spent on it will return you back.

Expect that you will have to learn at least 2-3 months,
to begin understanding the problematic. Use filemon/filespy,
write your own file test program and watch the operations
in kernel mode as result of user mode calls. This should
give you an overview to the whole problematics.

Don’t let your management believe that the task is easy,
decisions like “we just add a few modifications to filespy
and it will work” usualy end in much longer development
times than originally planned.

L.

[amitr0-2]

This is perhaps the most valuable suggestion anyone has given in the list.
All will benifit. Thanks ladislav.

But hey, still I personally would like to know as to why some one in this
discussion pointed out not to use filemon as a reference. Is it because it
is copyrighted? Can someone enlighten me. I am just curious. So would be the
original poster in this thread.