Hello,
My question is related to the altitude management.
Our product has a mini filter driver that modifies file names.
If some filter above catches the request before us, the file name can still be “incorrect”, which might break the other product’s functionality.
What’s the right way making sure we have the highest altitude? Is registering with MS the only way?
I have thought of using crazy strings like “9999999999999999”, but it surely must be a wrong way of doing this. Is there any case of “watching” for drivers attaching above and reattaching with an increased altitude?
Thanks in advance,
Greg.
Consider another product that is similar to yours, and needs to be on top 
Both of you can’t be right… so you are breaking their functionality or they are breaking yours. IN such a situation, being in the top altitude group (registering) is all you can do.
xxxxx@gmail.com wrote:
Hello,
My question is related to the altitude management.
Our product has a mini filter driver that modifies file names.
If some filter above catches the request before us, the file name can still be “incorrect”, which might break the other product’s functionality.
What’s the right way making sure we have the highest altitude? Is registering with MS the only way?
I have thought of using crazy strings like “9999999999999999”, but it surely must be a wrong way of doing this. Is there any case of “watching” for drivers attaching above and reattaching with an increased altitude?
Thanks in advance,
Greg.
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars 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
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
This is a very old question and the answer is you cannot guarantee this
EVER! Think about it, what happens if you do come up with a crazy
schema for doing it, someone else may have the same requirement and you
will lose. Also the clever developer can create a legacy filter that
goes above any minifilter at which point you lose. YOUR PRODUCT IS
INCORRECTLY DESIGNED AND CODED IF YOU HAVE A REQUIREMENT LIKE THIS.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@gmail.com” wrote in message
news:xxxxx@ntfsd:
> Hello,
>
> My question is related to the altitude management.
> Our product has a mini filter driver that modifies file names.
> If some filter above catches the request before us, the file name can still be “incorrect”, which might break the other product’s functionality.
> What’s the right way making sure we have the highest altitude? Is registering with MS the only way?
> I have thought of using crazy strings like “9999999999999999”, but it surely must be a wrong way of doing this. Is there any case of “watching” for drivers attaching above and reattaching with an increased altitude?
>
> Thanks in advance,
> Greg.
Hi,
Thanks for the answers. Please do not point me to the obvious, it’s not a matter of a cat and a mouse game The goal is not to “win over” another product, but just to minimize chances of breaking one. Just for an example, consider there’s a redirector driver, which accepts file names, which are cryptic to any other component before the redirection. What’s wrong with the design?
Regards,
G.
> Thanks for the answers. Please do not point me to the obvious, it’s not a matter of a cat and a mouse game The goal is not to “win over” another product, but just to minimize chances of breaking one. Just for an example, consider there’s a redirector driver, which accepts file names, which are cryptic to any other component before the redirection. What’s wrong with the design?
Incompatibility with similar products? Nothing else. You can be in the altitude group for such filters. If you get a specific situation where that doesn’t work, you can look for what’s wrong and/or try to work around it. But, that is enough in a correct system.
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
Hi Gregory,
There are quite a few filters out there that change file names. You don’t need to be the topmost filter to do that. In fact, most such filters belong in the virtualization altitude range which is about in the middle of the stack.
The only supported way to get an altitude is through MS. Also, requesting to be the topmost filter won’t work since MS gets one this requests about once a month :).
Could you please explain why you think that if another filter above yours catches the name it will be behave incorrectly ?
Thanks,
Alex.
Hi Alex,
Let me explain, without going too specific about the situation.
Suppose, you implement a version control product, which understands names
in the form filename$V1.txt. The file itself is named filename.txt, but by
seeing V1 in the name, the driver knows it should access the version 1 of
it. So, it just strips the $V1 suffix and possibly modifies the path to
point to VERSIONS\1\filename.txt. Now, suppose some other driver catches
the request before me and sees the unmodified name (filename$V1.txt). If it
tries to do something with the file (i.e. open it), it will fail as no such
file actually exists.
G.
On Mon, Mar 19, 2012 at 7:05 PM, wrote:
> Hi Gregory,
>
> There are quite a few filters out there that change file names. You don’t
> need to be the topmost filter to do that. In fact, most such filters belong
> in the virtualization altitude range which is about in the middle of the
> stack.
>
> The only supported way to get an altitude is through MS. Also, requesting
> to be the topmost filter won’t work since MS gets one this requests about
> once a month :).
>
> Could you please explain why you think that if another filter above yours
> catches the name it will be behave incorrectly ?
>
> Thanks,
> Alex.
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars 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
>
Look at “name provider” stuff.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntfsd…
> Hi,
>
> Thanks for the answers. Please do not point me to the obvious, it’s not a matter of a cat and a mouse game The goal is not to “win over” another product, but just to minimize chances of breaking one. Just for an example, consider there’s a redirector driver, which accepts file names, which are cryptic to any other component before the redirection. What’s wrong with the design?
>
> Regards,
> G.
>
Wouldn’t you modify the call for filters above you as well??
Greg wrote:
Hi Alex,
Let me explain, without going too specific about the situation.
Suppose, you implement a version control product, which understands
names
in the form filename$V1.txt. The file itself is named filename.txt,
but by
seeing V1 in the name, the driver knows it should access the version 1
of
it. So, it just strips the $V1 suffix and possibly modifies the path
to
point to VERSIONS\1\filename.txt. Now, suppose some other driver
catches
the request before me and sees the unmodified name (filename$V1.txt).
If it
tries to do something with the file (i.e. open it), it will fail as no
such
file actually exists.
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
Thanks Maxim, this is a new direction.
On Mon, Mar 19, 2012 at 7:16 PM, Maxim S. Shatskih
wrote:
> Look at “name provider” stuff.
>
> –
> Maxim S. Shatskih
> Windows DDK MVP
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> wrote in message news:xxxxx@ntfsd…
> > Hi,
> >
> > Thanks for the answers. Please do not point me to the obvious, it’s not
> a matter of a cat and a mouse game The goal is not to “win over” another
> product, but just to minimize chances of breaking one. Just for an example,
> consider there’s a redirector driver, which accepts file names, which are
> cryptic to any other component before the redirection. What’s wrong with
> the design?
> >
> > Regards,
> > G.
> >
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars 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
>
Hi Dejan,
How is that possible? They have already got it before me. Or did I
misunderstand your question?
G.
On Mon, Mar 19, 2012 at 7:17 PM, Dejan Maksimovic wrote:
>
> Wouldn’t you modify the call for filters above you as well??
>
> Greg wrote:
>
> > Hi Alex,
> >
> > Let me explain, without going too specific about the situation.
> > Suppose, you implement a version control product, which understands
> > names
> > in the form filename$V1.txt. The file itself is named filename.txt,
> > but by
> > seeing V1 in the name, the driver knows it should access the version 1
> > of
> > it. So, it just strips the $V1 suffix and possibly modifies the path
> > to
> > point to VERSIONS\1\filename.txt. Now, suppose some other driver
> > catches
> > the request before me and sees the unmodified name (filename$V1.txt).
> > If it
> > tries to do something with the file (i.e. open it), it will fail as no
> > such
> > file actually exists.
>
> –
> Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
> http://www.alfasp.com
> File system audit, security and encryption kits.
>
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars 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
>
App tries to open FileName$v1.txt, you modify it to
\VERSIONS\1\Filename.txt - all happy
If there is a filter above you, it sees FileName$v1.txt, tries to
open it - that open goes through your filter, which redirects it to
\VERSIONS\1\Filename.txt - all happy?
Greg wrote:
Hi Dejan,
How is that possible? They have already got it before me. Or did I
misunderstand your question?
G.
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
So the filters above you will get the filename$v1.txt and when they try to open it the request will go through your filter which will change filename$V1.txt to whatever it needs to be and everything should work fine.
WHy wouldn’t this model work ?
THanks,
Alex.
Hi guys,
This is indeed, the “all happy” scenario
I probably exaggerated the problem.
Still, if the product above logs the file names, it will log the incorrect ones.
This is, however, of much less concern to me.
Thanks a lot!
Even if it logs the name it shouldn’t be a problem. If the namespace is consistent (so they can open those names and they always get the same name for the same file and so on) everything should be fine.
Microsoft’s own LUAFV file system filter does the same thing.
Expecting that the namespace that the user sees is the same as the namespace at the file system level is the same as expecting that if you write some bytes in a file you will be able to find them by reading the disk at the block level. There may be many other filters doing encryption, compression, virtualization and so on…
Thanks,
Alex.
Thanks Alex, that’s a good point.
G.
On Mar 19, 2012, at 19:41, xxxxx@gmail.com wrote:
Even if it logs the name it shouldn’t be a problem. If the namespace is consistent (so they can open those names and they always get the same name for the same file and so on) everything should be fine.
Microsoft’s own LUAFV file system filter does the same thing.
Expecting that the namespace that the user sees is the same as the namespace at the file system level is the same as expecting that if you write some bytes in a file you will be able to find them by reading the disk at the block level. There may be many other filters doing encryption, compression, virtualization and so on…
Thanks,
Alex.
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars 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
On 03/19/2012 10:32 AM, xxxxx@gmail.com wrote:
> Hi guys,
>
> This is indeed, the “all happy” scenario
> I probably exaggerated the problem.
> Still, if the product above logs the file names, it will log the
incorrect ones.
> This is, however, of much less concern to me.
I might be reading this wrong, but this sounds like usermode would see
names from the on-disk view.
This is what happens when you have a minifilter that manipulates names
but does not implement the name provider APIs. Name queries by filters
before you may see a cached view of the name which originated from
beneath you. When it tries to use the name, bad things can happen.
It is important that when manipulating names, fltmgr’s cache coherency
is maintained via the name provider APIs.
There is a sample for this (that I worked on), which I knew was
distributed at plugfest, I don’t know if it has been incorporated in a
public release. You might want to check the Win8 WDK to see if it’s there.
I can vouch from experience though that it is possible to implement name
changing in a single layer, where layers above the filter have one view
and layers beneath it have a different view.
Hi Malcolm,
Thanks a bunch for the comment.
In my specific case, the incoherence isn’t an issue due to the implementation specifics I cannot go into here. But it’s extremely useful to know anyway.
G.
On Mar 20, 2012, at 3:18, “Malcolm Smith [MSFT]” wrote:
> On 03/19/2012 10:32 AM, xxxxx@gmail.com wrote:
> > Hi guys,
> >
> > This is indeed, the “all happy” scenario
> > I probably exaggerated the problem.
> > Still, if the product above logs the file names, it will log the incorrect ones.
> > This is, however, of much less concern to me.
>
> I might be reading this wrong, but this sounds like usermode would see names from the on-disk view.
>
> This is what happens when you have a minifilter that manipulates names but does not implement the name provider APIs. Name queries by filters before you may see a cached view of the name which originated from beneath you. When it tries to use the name, bad things can happen.
>
> It is important that when manipulating names, fltmgr’s cache coherency is maintained via the name provider APIs.
>
> There is a sample for this (that I worked on), which I knew was distributed at plugfest, I don’t know if it has been incorporated in a public release. You might want to check the Win8 WDK to see if it’s there.
>
> I can vouch from experience though that it is possible to implement name changing in a single layer, where layers above the filter have one view and layers beneath it have a different view.
>
> - M
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars 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