Hello Ganesh
This is kernel so all sorts of stuff is possible. I suppose in your scenairo
you should be asking yourself if there is a filter between filespy and
minifilter and if os what that filter is doing. I think however that you
should use windbg to follow the irp from filespy dow the stack and learn
what heppens then. In thi smanner you will should learn the answer to your
question I think. If you can not do this, because you arecnt capable, thne
the chances are you are not really at the stage where posting to nfsd - or
for that matter wokring on the file systems stack - is appropriate - but I
assume you are able to do this - so I hope that you will folow the irp and
report here what you have found, for the benefit of te community as a whole.
I, for one, look forward to hearing from you the answer in this case.
Best Wishes
Lyndnon
“ganesh pashupathi” wrote in message
news:xxxxx@ntfsd…
Hi,
Kindly accept my apologies for reposting the issue. Is there a scenario
where the legacy filter will receive a setinformation with rename flag set
while the minifilter would not.
My scenario occurs in Clearcase drive (not always though).
- Go to command prompt.
- rename 1.txt to 2.txt.
File spy as a legacy filter gets the set information with rename flag. While
File spy as mini filter does not get the set information call. Similarly my
mini-filter does not get the call as well.
Kindly provide me with some pointers.
Thanks a lot,
~ganesh
Hello Ganesh
I see you infer that no rename occurs - the Irp isnt sent below mvfs - and
this might indeed be correct - on the other hand perhaps mvfs sends the Irp
direct to the file system driver? I dont know let me be clear here and now I
do not suggst that mvfs does [or does not] behave in this manner because I
have no knowledge of that matter. I just that it is in principle possible
for a filter driver to behave in such manner.
It seems from your text you believe you have a requirement that your filter
attaches to the device stack -after- mvfs attaches to the device stack. This
seems to be the subject matter of load order groups perhaps which you can
read about in IFS/WDK … I hope that allows you to deleiver your
requirements!
Filter driver interop can be tough …
Best Wishes
Lyndon
“ganesh pashupathi” wrote in message
news:xxxxx@ntfsd…
Hi Lyndon,
Many thanks for your reply.
I was able to debug the scenario (Currently I understand the problem but
looking for a solution). Following is what I tried.
1. Loaded my filter FilterA at boot start. (Very simple filter which only
traps rename and dbg prints the file name).
2. Loaded file spy after the user logged on to the machine and accessed the
clear case mapped drive e.g. Z: at least once.
3. Placed a breakpoint in the file spy where the rename event was seen.
4. From there on stepped through till the rename operation was completed.
Local disk scenario where all works well:
- The call goes to the file spy.
- File spy sends it to the Rational Clearcase mvfs driver.
- The Clearcase mvfs driver sends the call to filter manager which then
dispatches it to my filter.
- All works well.
Clearcase View location:
- The call comes to filespy.
- File spy sends it to the Rational Clearcase mvfs driver.
- Mvfs driver does not send the call below.
- Filter manger does not receive the call at all.
Mvfs driver does not send the rename call below (may be) because there is no
rename happening in the Clearcase view storage (I am giving a
summary information here and if you are not aware of Clearcase then I will
have to write in some more detail).
Clearcase creates a virtual file system. A volume \device\mvfs is created.
There is a local storage that is created where all the checked out
and files not added to Clearcase are kept e.g. D:\CC_Views. There is a
similar view store that is created on the Clearcase server that stores
all the checked in files. The users view the file through another mapped
location Z:\Test\a.cpp. If a.cpp is checked out it is shown from the
local storage else it is shown from the server storage.
The user opens a file from a mapped drive e.g. Z:\Test\a.txt. This
file however is present either on a server location (if the file is not
checked out) or it is present on the local Clearcase storage e.g.
D:\CC_Views\View_name.s\00012\8000000f4607ebf0a.txt.
When a rename operation is done from command prompt
e.g. ren a.txt b.txt
The name in Z: is changed to b.txt however in the view storage the file is
still the same
D:\CC_Views\View_name.s\00012\8000000f4607ebf0a.txt.
Finally, my filter should be loaded after mvfs attached to the Z: drive.
Also after the machine restarts and after accessing the Z drive with
the help of explorer if I load my filter then my filter gets the rename
event. Other wise my filter does not get the rename event.
mvfs is a legacy driver. Its group is Network group and it depends on the
TDI driver. Its start type is set to 3 i.e. on demand start.
I am still looking more into this. Meanwhile if you have any pointers that
would be really helpful.
Thanks a lot,
~ganesh
On Sat, 21 Apr 2007 Lyndon J Clarke wrote :
>Hello Ganesh
>
>This is kernel so all sorts of stuff is possible. I suppose in your
>scenairo
>you should be asking yourself if there is a filter between filespy and
>minifilter and if os what that filter is doing. I think however that you
>should use windbg to follow the irp from filespy dow the stack and learn
>what heppens then. In thi smanner you will should learn the answer to your
>question I think. If you can not do this, because you arecnt capable, thne
>the chances are you are not really at the stage where posting to nfsd - or
>for that matter wokring on the file systems stack - is appropriate - but I
>assume you are able to do this - so I hope that you will folow the irp and
>report here what you have found, for the benefit of te community as a
>whole.
>I, for one, look forward to hearing from you the answer in this case.
>
>Best Wishes
>Lyndnon
>
>“ganesh pashupathi” wrote in message
>news:xxxxx@ntfsd…
>Hi,
>
>Kindly accept my apologies for reposting the issue. Is there a scenario
>where the legacy filter will receive a setinformation with rename flag set
>while the minifilter would not.
>
>My scenario occurs in Clearcase drive (not always though).
>- Go to command prompt.
>- rename 1.txt to 2.txt.
>
>File spy as a legacy filter gets the set information with rename flag.
>While
>File spy as mini filter does not get the set information call. Similarly my
>mini-filter does not get the call as well.
>
>Kindly provide me with some pointers.
>
>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: xxxxx@rediffmail.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com
Hello again
I’ve never had the pleasure of Clearcase so know almost nothing about mvfs.
Here are some questions you might be able to answer for yourself. This mvfs
*is* a file system *filter* driver right? Is it some form of layered file
system? Like I said I know almost nothing about mvfs. I dont know whether
your driver is a file system filter driver or a mini-filter driver. Whataver
you might want to use a tool like DeviceTree (OSR) to have a look at what is
attached to what in terms of file systems, filter manager, filter drivers,
this mvfs driver …
It sounds like you have some form of interop problem with Clearase and this
mvfs driver so if you need to pursue that I’d assume you’d be best off
working with Clearcase developers.
Good luck
Lyndon
“ganesh pashupathi” wrote in message
news:xxxxx@ntfsd…
Hi Lyndon,
I checked this with Irp tracker as well. The rename call goes through
several filters and then goes to mvfs which does not send the irp to lower
level filter.
I looked at the load order documentation. There is one scenario that I do
not understand.
The startup type for MVFS is marked as Demand start in the registry. However
it loads during startup of the machine. I can see this with Dbgview that is
marked for log boot. I have configured my mini-filter to start after the
mvfs driver starts. Now my machine starts and I logon on to the machine. I
launch Dbgview and verify that my filter has indeed loaded after mvfs. Now I
go to the mapped drive Z: which is the clearcase virtual drive. This drive
is shown as a disconnected network drive. If I right click on the drive
letter Z: and then check properties the drive type is shown as Raw. If I
double click on Z: it takes a while to connect and then if I right click to
view the properties I can see the drive type as MVFS. If I rename the file
now my filter still does not trap the rename.
My filter will trap rename if and only if my filter is loaded after MVFS is
loaded and Z: is accessed atleast once.
MVFS is loaded at startup time. My filter is also loaded at startup time
after MVFS. What could be happening at the time I double click on Z:? Why
does the call go to MVFS even though my filter is on the top of the stack if
I load my filter after mvfs but before accessing Z:?
Thanks a lot,
Ganesh
On Fri, 04 May 2007 ganesh pashupathi wrote :
>Hi Lyndon,
>
>Many thanks for your reply.
>
>I was able to debug the scenario (Currently I understand the problem but
>looking for a solution). Following is what I tried.
>
>1. Loaded my filter FilterA at boot start. (Very simple filter which only
>traps rename and dbg prints the file name).
>2. Loaded file spy after the user logged on to the machine and accessed the
>clear case mapped drive e.g. Z: at least once.
>3. Placed a breakpoint in the file spy where the rename event was seen.
>4. From there on stepped through till the rename operation was completed.
>
>Local disk scenario where all works well:
>- The call goes to the file spy.
>- File spy sends it to the Rational Clearcase mvfs driver.
>- The Clearcase mvfs driver sends the call to filter manager which then
>dispatches it to my filter.
>- All works well.
>
>Clearcase View location:
>- The call comes to filespy.
>- File spy sends it to the Rational Clearcase mvfs driver.
>- Mvfs driver does not send the call below.
>- Filter manger does not receive the call at all.
>
>Mvfs driver does not send the rename call below (may be) because there is
>no rename happening in the Clearcase view storage (I am giving a
>
>summary information here and if you are not aware of Clearcase then I will
>have to write in some more detail).
>
>Clearcase creates a virtual file system. A volume \device\mvfs is created.
>There is a local storage that is created where all the checked out
>
>and files not added to Clearcase are kept e.g. D:\CC_Views. There is a
>similar view store that is created on the Clearcase server that stores
>
>all the checked in files. The users view the file through another mapped
>location Z:\Test\a.cpp. If a.cpp is checked out it is shown from the
>
>local storage else it is shown from the server storage.
>
>The user opens a file from a mapped drive e.g. Z:\Test\a.txt. This
>
>file however is present either on a server location (if the file is not
>
>checked out) or it is present on the local Clearcase storage e.g.
>D:\CC_Views\View_name.s\00012\8000000f4607ebf0a.txt.
>
>When a rename operation is done from command prompt
>e.g. ren a.txt b.txt
>
>The name in Z: is changed to b.txt however in the view storage the file is
>still the same
>
>D:\CC_Views\View_name.s\00012\8000000f4607ebf0a.txt.
>
>Finally, my filter should be loaded after mvfs attached to the Z: drive.
>Also after the machine restarts and after accessing the Z drive with
>
>the help of explorer if I load my filter then my filter gets the rename
>event. Other wise my filter does not get the rename event.
>
>mvfs is a legacy driver. Its group is Network group and it depends on the
>TDI driver. Its start type is set to 3 i.e. on demand start.
>
>I am still looking more into this. Meanwhile if you have any pointers that
>would be really helpful.
>
>Thanks a lot,
>~ganesh
>
>
>On Sat, 21 Apr 2007 Lyndon J Clarke wrote :
> >Hello Ganesh
> >
> >This is kernel so all sorts of stuff is possible. I suppose in your
> >scenairo
> >you should be asking yourself if there is a filter between filespy and
> >minifilter and if os what that filter is doing. I think however that you
> >should use windbg to follow the irp from filespy dow the stack and learn
> >what heppens then. In thi smanner you will should learn the answer to
> >your
> >question I think. If you can not do this, because you arecnt capable,
> >thne
> >the chances are you are not really at the stage where posting to nfsd -
> >or
> >for that matter wokring on the file systems stack - is appropriate - but
> >I
> >assume you are able to do this - so I hope that you will folow the irp
> >and
> >report here what you have found, for the benefit of te community as a
> >whole.
> >I, for one, look forward to hearing from you the answer in this case.
> >
> >Best Wishes
> >Lyndnon
> >
> >“ganesh pashupathi” wrote in message
> >news:xxxxx@ntfsd…
> >Hi,
> >
> >Kindly accept my apologies for reposting the issue. Is there a scenario
> >where the legacy filter will receive a setinformation with rename flag
> >set
> >while the minifilter would not.
> >
> >My scenario occurs in Clearcase drive (not always though).
> >- Go to command prompt.
> >- rename 1.txt to 2.txt.
> >
> >File spy as a legacy filter gets the set information with rename flag.
> >While
> >File spy as mini filter does not get the set information call. Similarly
> >my
> >mini-filter does not get the call as well.
> >
> >Kindly provide me with some pointers.
> >
> >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:
> >xxxxx@rediffmail.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